Some more refinements to v5 migration to get a few more systems over the line.

Includes DB changes ,you need to log all terminals out during upgrade

Fixes and tweaks

• Cash / Bank Reconciliation. Couple more exotic scenarios
  • 1) Do a cash-till reconcile on period A -> B which was previously reconciled.  If since rec some txns were backdated into A->B period and into before A as well, and as part of cash till you try and record banked changes at the same time, under some certain combinations the save would fail. (discordant txn list from journalrec_base would alter on posting the banked txn and how that txn influences the old reconcile, when in reality it shouldn't make any difference
  • 2) re-do a reconcile. Held over txns that where previously okayed in overlaid rec would come through as ok, but effect of overlaid rec should be ignored in this scenario, forcing the user to redo handling of heldover txns and reconsider the reconcile that precedes chronologically
• Payroll tweaks, for STP phase 2 : included alternative tax table computation, that uses linear equations & formulas ATO publishes in NAT spreadsheets, as opposed to using progressive tax tables ATO also publish, to help smooth out STP Phase 2 compliance
• View/Change part quick stock order. 'Daily' and 'Alt' buttons would still order part under stock. Now fixed.

Includes DB changes, you need to log all terminals out during upgrade

Tweaks and fixes

• Bank / Cash reconciliation.
  • A specific set of behaviours would generate unexpected reconciliation results. If you backdate a txn and redo cash till on that date where final balance changes, the following days cash till would seem okay, but day after would correctly highlight some sort of discordant reconciliation error. Now fixed so discordant reconciliation error appears immediately on next day as well.
  • Separate out discordant txn tally into a separate column in cash till, so does not merge figure into in/out columns. Should hopefully make dealing with cash tills broken by things such as backdated txns a bit more intuitive.
• Create labour rate. Fix long standing bug where under some circumstances the rate would be ex GST
• spares complete: allow 3 digit negative freight value entry.
• finished deals: view deposit history from here.
• reconcile txns button on view txns would look at customer type to figure out what class of txns to reconcile. Now preferentially looks at what sort of txn is currently highlighted. Needed where cust type and txn type do not align or are ambiguous (as in case of contacts who are both suppliers & debtors)
• Color code deals based on deal/quote and whether or not their pickup date is today/in the past
• Unit deal that is invoiced, rolled back and reinvoiced which has rebates defined on the deal itself. Re-invoice would fail with a save mode error, now fixed
• print a4 spares receipt. Make depositing printed the initial deposit only. Print a 'time of print' deposit history on the a4 invoice

txnscript : This version of c9 includes a new diagnostic tool to help us do more advanced diagnostics and repairs on c9. For last 10 years, advanced support relied on direct access to the database. But direct DB is no longer adequate with v5, as v5s database structure is too complex to manage this way. The tool is a beanshell like scripting engine called txnscript designed specifically for v5 c9. Given direct access to c9 db is too complex to manage directly, the old DB scanner tool has been removed.

Bugfixes with 'use deposit to pay new account sale' behaviour. Would consistently fail with an error along lines of 'Cowardly refusing to add a txn without a customer' and would write changes which would be damaged.

Tweaks and fixes

• Unit wrangling changes in 5.1.26 were done incorrectly. On payout of a unit added from v4, c9 could throw an error. Now fixed
• Convert rebate to invoice was not properly migrated to v5. Now fixed.

• Rebate recording : was allocating rebates against configured floorplan bank, not rebate bank. Now fixed.

Bugfix with cash till screen, profit summary. The profit summary figures would tally in inconsistent and unreliable ways if there are unsaved bank/float changes on cash till screen. Also if you drill into txn list with unsaved lines on it you'll see weird looking lines like screengrab below (root cause is partial memory corruption while processing unsaved lines).  On saving things fix themselves up. Issue is now fixed for unsaved lines too.

Prior version:

Fixed version:

More work on migration to v5

Includes DB changes, you need to log all terminals out during upgrade

• Bank reconciliation : if you flagged a txn as ignored on a prior rec and since then changed the txn lines GL code so it is no longer part of the bank/instrument being reconciled, c9 would still think the txn needed to be reconciled and resulting rec would fail with do not save. Now fixed (txnline is filtered out of rec)
• Apply WS estimates which involve sublets not working correctly. Would not apply the change and report an error. Now fixed.
• Deposit fixes
  • Deposit + WS estimate application at same time would blow up. Now fixed
  • Deposit application could potentially print receipt before txn was safely saved to database which in theory could mean a receipt could pop out but no record of txn make it because of system error or otherwise. Modified deposits to align with strict rule that printing only happens for safely recorded data.
  • Forfeit deposit printout : show payment line underneath subtotals
  • Delete spares deposit via business -> activity was too permissive. Now tightened up.
• Unit wrangling such as recording a curtailment. Do not try to rewrite the original unit purchase if it predates BAS / GL lock and contains old V4 era txn lines.
• BAS/GL locking
  • if day is set to 1st then permit loose locking. Allow changes as long as net impact within a given month is zero. BAS already worked this way by default. This change also applies to GL lock.
  • Add a new GL lock : strict. Do not allow any changes at all before GL lock
• Low level v5 changes : tweaks to how some things are amortized such as GST to that targets which start at zero and express a bias, +ve/-ve or don't care. This prevents materialized tax on lines ever going -ve because amortization started on a line with initial GST of 0 and amortization required to round down).

Modules: c9, c9lib, txnengine

• Bugfix with bad version number hygiene.  If you upgraded to 5.1.24 from 5.1.23 then payroll would break with an error. If you skipped 5.1.23 (e.g. upgraded from 5.1.22) then would work fine.  Fixed here for dealers who are having this issue
• New job : nag user on close window without saving new job incase they clicked on cancel button accidently
• Bugfix with received orders report. Under some circumstances if you rerun the report the new report would mash data from prior run into new report, effectively causing the report to double up its results. Now fixed.