Hi Luke, On Sun, Jun 19, 2011 at 9:56 PM, Luke <account...@lists.tacticus.com> wrote: > On Sun, 19 Jun 2011, Erik Huelsmann wrote: > >> the check marks in the screen say "Include in selection list"; a user >> might deselect the check marks, resulting in the above logic to >> conclude that the account is no longer a tax account. The conclusion >> is incorrect of course. > > For sanity's sake, those checkmarks should revert to unchecked, and the > properties not be saved, if the tax checkbox is not selected. > > If it's not selected as a tax account, it shouldn't be permitted to appear > in tax dropdowns. > That will prevent accidentally selecting it for dropdowns, but forgetting > to mark it as a tax account.
Good point. I'll look into implementing something that prevents this situation. >> On gTalk, we agreed the best course of action is to add a >> characteristic to the account's 'account' record to say it's a tax >> account. When that check mark is selected, there should also be a row >> in the 'tax' table which describes the calculation rules to be >> applied. We should probably deny changing the 'tax' check mark after >> the account has been posted to though [if we really want that, I >> should look into triggers in the database to achieve that goal; no >> idea off hand how to arrange that denial]. > > Why? > > I mean, I know it would be kind of nonsensical to uncheck that box after > the fact, but if for some reason someone really wanted to, maybe they > should be able to. Well, the reason I'm interested in disabling this is: what are the chances of the application failing operation if someone would. Same way the other way around: what would happen if an account would be marked as Tax after it's been posted onto? Can we estimate all effects? If not, does it matter that it just gets disabled? As an anecdote: I was in a company where they created a P&L account, but set it up - accidentally - as a balance sheet account. Once the account went into production, there was *no* way to switch it to balancesheet. It had to be disabled; there also was *no* way of removing it. The system is one from a huge (closed source) vendor, so, in my view, the behavior I'm proposing isn't really all that weird. > So I'll ask the question: is there any conceivable reason why someone > might want to uncheck a tax account? No. But if they can, maybe they do - even if only by accident. > The only one I can think of, is someone wanting to temporarily prevent > that tax from being calculated or included. You could achieve that goal by setting the tax percentage to 0% instead of removing the account. Typically the account gets assigned as 'applicable' to customers and parts. Will all those functions keep working correctly if it's unchecked from Tax -- and the associated tax percentages removed by consequence? > I don't know why you'd want to do that, either, but I don't know > everything everyone might need to do under unusual circumstances. True. But we might be able to estimate the impact on the application and form an idea if it's wise to want to do :-) Bye, Erik. ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
