All versions from 1.3.0 to 1.11.16 are affected by a bug in Cost of Goods Sold (COGS) accounting for assemblies: Instead of accounting expenses and reducing inventory, negative expenses are posted, putting goods into inventory.
I never used assemblies; am I affected too?
No. Only if you used assemblies in combination with LedgerSMB 1.3.0 through 1.11.15, you're affected.
What is the impact of this bug?
There is a balance sheet and an income statement effect to this bug: because negative expenses have been reported, profit has been overstated. Similarly, because inventory was increased instead of reduced, assets are overstated. The impact of this on your tax returns is to be established by a certified accountant or bookkeeper in your jurisdiction.
What does the fix do?
On one hand, the fix ensures that assembly COGS are accounted for correctly, effective from the upgrade. It does this by both fixing the root cause and repairing data produced by the root cause that would lead to incorrect future accounting.
Additionally, the fix has a one-off procedure to identify historically incorrect data. Based on the identified data, a batch with correction postings will be created. This batch is not posted, instead, it is available under the "Transaction Approval > Batch" menu as a proposed correction. The batch contains a (draft) transaction for each month in which a COGS correction is required. That is, each month in which correctable COGS have been posted.
What about closed periods?
As it's impossible to post in closed periods, the proposed fixes for closed months will be dated on the first day of the current open period. By opening the books on the desired date (or removing closed periods entirely) before running the migration procedure, it's possible to regulate at which date these transactions will be proposed: either at the end of the affected period, or at the beginning of the first open period.
What if I don't want these historic fixes?
If you don't want these historic fixes, e.g. because you want to post your own, simply delete the correction batch. Please note that - behind the scenes - the correction transactions link to the sales transactions and assemblies for which they are a correction. Deleting the batch will remove that link.
If you want to retain the link, but don't want to accept the proposed batch as-is and opening the books on a certain date before migration doesn't provide sufficient solution for your situation, the last option is to contact the development team or find commercial support.
I'm still on 1.10; will I get the fix?
This bug isn't released for 1.10, although a month of community support remains: the project team decided that the fix is too invasive. The solution to getting the fix is to upgrade to 1.11.