Consequences of the fact that they do not share a common sequence anymore:
status table data from orders is linked to invoices and vice versa; invoice status may overwrite/add to orders data- Recurring orders don't work (I've even hidden the buttons). It hasn't worked for 14 years (due to overlapping number ranges in
oe.id versus transactions.id) and has been aggravated for the last 8 years by an integrity constraint of recurring.id against transactions.id, completely blocking the ability to add schedules to orders, except when there's accidental overlap in the number ranges (which is more likely to be hazardous than a intentional.)
goods__history (
|
JOIN (select id, trans_id, parts_id, sellprice, qty, discount, serialnumber, |
|
'o' as i_type |
|
FROM orderitems |
|
UNION |
|
SELECT id, trans_id, parts_id, sellprice, qty, discount, serialnumber, |
|
'i' as i_type |
|
FROM invoice) i ON p.id = i.parts_id |
) joins trans_id retrieved from both oe as well as ar/ap (i.e. transactions), which is similarly broken to recurring orders
Consequences of the fact that they do not share a common sequence anymore:
statustable data from orders is linked to invoices and vice versa; invoice status may overwrite/add to orders dataoe.idversustransactions.id) and has been aggravated for the last 8 years by an integrity constraint ofrecurring.idagainsttransactions.id, completely blocking the ability to add schedules to orders, except when there's accidental overlap in the number ranges (which is more likely to be hazardous than a intentional.)goods__history(LedgerSMB/sql/modules/Goods.sql
Lines 519 to 525 in 33c601f
trans_idretrieved from both oe as well asar/ap(i.e.transactions), which is similarly broken to recurring orders