Re: [Ledger-smb-devel] Tax account creation: how to 'detect' tax accounts?
I went ahead and committed the changes to do this, without the JS buttons which proved to be more trouble than they were worth. Current rules: 1) If tax basis is blank, fills in from total of line items selected to be taxable for this tax. 2) If rate is blank, fills in from tax rate 3) If amount is blank, fills in as rate * basis. Best Wishes, Chris Travers -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
Re: [Ledger-smb-devel] Tax account creation: how to 'detect' tax accounts?
So I am starting work on this while waiting for the file attachment side to be discussed a bit more. I'm thinking it should be correlated with a regular tax account, so that you can flag customers/parts for whether it's relevant (and have a mix of taxable/non-taxable items on it). Then provide these fields 1. Reference (e.g. location id) 2. Description (text field, optional) 3. Percentage 4. Amount ... that would be one line per invoice that could be filled in. I'm thinking it would be nice to calculate amount from applying percentage to taxable items on the invoice, if amount is blank. I also think for maximum flexibility it should be possible to leave percentage blank and provide an amount instead. Then in the tax report for that account, provide a spreadsheet download with the collected details. What I think I am going to do is provide a JS button for the calculation. Additional field will be taxable amount, and this will be prepopulated with the taxable amount. The rate will be prepopulated with the tax rate set up. One can then change either, click calculate and let it calculate. Best Wishes, Chris Travers -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
Re: [Ledger-smb-devel] Tax account creation: how to 'detect' tax accounts?
At the moment, our customers actually pay via another system (Drupal/Ubercart) which already does the right thing for taxes -- it does a call to a web service run by the State of Washington which returns the appropriate location code and rate. Basically what I need from LedgerSMB is a blank line item I can populate with this data, that is clearly a tax line, exported for reporting. If I can export the tax report detail to ODS, I can then slice it up per location code to file the taxes. That's a very good stopgap measure. Specifically what info would be stored? How can we make it generic? Best Wishes, Chris Travers -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev ___ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
Re: [Ledger-smb-devel] Tax account creation: how to 'detect' tax accounts?
On 06/22/2011 04:15 PM, Chris Travers wrote: At the moment, our customers actually pay via another system (Drupal/Ubercart) which already does the right thing for taxes -- it does a call to a web service run by the State of Washington which returns the appropriate location code and rate. Basically what I need from LedgerSMB is a blank line item I can populate with this data, that is clearly a tax line, exported for reporting. If I can export the tax report detail to ODS, I can then slice it up per location code to file the taxes. That's a very good stopgap measure. Specifically what info would be stored? How can we make it generic? I'm thinking it should be correlated with a regular tax account, so that you can flag customers/parts for whether it's relevant (and have a mix of taxable/non-taxable items on it). Then provide these fields 1. Reference (e.g. location id) 2. Description (text field, optional) 3. Percentage 4. Amount ... that would be one line per invoice that could be filled in. I'm thinking it would be nice to calculate amount from applying percentage to taxable items on the invoice, if amount is blank. I also think for maximum flexibility it should be possible to leave percentage blank and provide an amount instead. Then in the tax report for that account, provide a spreadsheet download with the collected details. Cheers, John Locke http://freelock.com -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev ___ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
Re: [Ledger-smb-devel] Tax account creation: how to 'detect' tax accounts?
On 06/20/2011 03:54 PM, Chris Travers wrote: SSTP is a mess. It's also the reason why a twix bar is not in the candy category but a snickers bar is. I don't know of any solution other than per-state tax modules to accommodate this. In our case, we don't have so many customers that it's a big burden to just add a new tax for the location of a customer who has a taxable transaction. So that's what I've been doing -- creating a new tax whenever we have a customer with a taxable transaction in a new location. The problem you highlight above is more about marking products as taxable or not -- that much, while muddy, is at least easily implemented today. The bigger problem is having tax rates that vary based on the customer's address, and a requirement to report a location code for each taxable transaction. At the moment, our customers actually pay via another system (Drupal/Ubercart) which already does the right thing for taxes -- it does a call to a web service run by the State of Washington which returns the appropriate location code and rate. Basically what I need from LedgerSMB is a blank line item I can populate with this data, that is clearly a tax line, exported for reporting. If I can export the tax report detail to ODS, I can then slice it up per location code to file the taxes. With that generic infrastructure in place, actually writing a module to populate that tax line as appropriate would be the next step... Is there a way to programmatically create an invoice today with a custom tax line? Cheers, John Locke http://freelock.com -- 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
Re: [Ledger-smb-devel] Tax account creation: how to 'detect' tax accounts?
On Mon, Jun 20, 2011 at 5:24 AM, Michael Richardson m...@sandelman.ca wrote: Luke == Luke account...@lists.tacticus.com writes: Luke Why? Luke I mean, I know it would be kind of nonsensical to uncheck that box after Luke the fact, but if for some reason someone really wanted to, maybe they Luke should be able to. Luke So I'll ask the question: is there any conceivable reason why someone Luke might want to uncheck a tax account? Because the tax in question has been abolished or it applicability has changed, and new stuff shouldn't have it applied ever. But, alas, there are things that need to be back dated or which a government tells you that you should have done it to. The only legitimate reason I can see would be if someone checked it by accident and wanted to uncheck it before things were really configured. It seems to me the simple answer is to disallow unchecking when the account exists in the tax table, i.e. has already been configured as a tax account. Best Wishes, Chris Travers -- 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
Re: [Ledger-smb-devel] Tax account creation: how to 'detect' tax accounts?
Chris Travers writes: The only legitimate reason I can see would be if someone checked it by accident and wanted to uncheck it before things were really configured. It seems to me the simple answer is to disallow unchecking when the account exists in the tax table, i.e. has already been configured as a tax account. If an out-of-state customer picks up his order I must collect Wisconsin and Pierce County sales tax. If I ship it to him I don't. If I ship to an in-state customer I must collect the sales tax (if any) for his county (as well as state tax) rather than mine. If he resides in a special tax district I may need to collect that tax, depending on the type of goods. If he picks it up I collect Pierce County tax. Thus depending on the location at which the sale is deemed to have occurred I may or may not have to collect one or more of several taxes from a given customer for a given transaction. I cannot classify a customer as always taxable or never taxable. -- John Hasler jhas...@newsguy.com Elmwood, WI USA -- 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
Re: [Ledger-smb-devel] Tax account creation: how to 'detect' tax accounts?
Hi, To summarize what the system currently has available (and how I think it's supposed to work) the tax stuff is controlled at several levels: 1. COA account -- whether an account contains tax transactions (and which screens to make it available on) 2. Customer/Vendor account -- whether a particular tax applies to a customer 3. Parts/Services -- whether a particular account applies to a part or service ... and then if a tax applies to both part and customer, the resulting calculation is applied to an invoice/order. I hear people saying (and we need this too) that we want to be able to change the above for a particular line item, adding 4. Line item is taxable. In 1.3, there is a new taxform checkbox on invoice lines, but I have no idea what that's for -- is that to override the default behavior? If not, I think it would be useful to have something like this -- generally to exclude tax from an item that would normally include tax. In our case, for customers who purchase both wholesale and retail -- sales tax applies to wholesale but not retail. But then we get into the reporting issue, because revenue from these sales would need to get reported to the state in a different account. So better might just be to make wholesale a completely different part, associated with a different account. But there is one other case -- destination-based sales tax. Currently our e-commerce system correctly does an address lookup with the state to get the correct sales tax rate and location code we need to report for taxable sales. LSMB of course does not. And since Washington currently has something like ~2000 individual locations, with varying tax rates, I think the other scenario, until we can build the appropriate tax module, is to just allow a person to calculate the appropriate tax (or in our case, post it from the other system that already handles it correctly) and add it as a separate line item to the invoice so everything matches up. So I guess I'd like to see some sort of invoice-level setting for apply tax automatically vs. add tax manually, and with the latter, a spot to put in the tax and enter an appropriate location code and rate that can be correlated in the future, in a spreadsheet download if nothing else. Cheers, John On 06/20/2011 05:55 AM, Chris Travers wrote: On Mon, Jun 20, 2011 at 5:24 AM, Michael Richardson m...@sandelman.ca wrote: Luke == Luke account...@lists.tacticus.com writes: Luke Why? Luke I mean, I know it would be kind of nonsensical to uncheck that box after Luke the fact, but if for some reason someone really wanted to, maybe they Luke should be able to. Luke So I'll ask the question: is there any conceivable reason why someone Luke might want to uncheck a tax account? Because the tax in question has been abolished or it applicability has changed, and new stuff shouldn't have it applied ever. But, alas, there are things that need to be back dated or which a government tells you that you should have done it to. The only legitimate reason I can see would be if someone checked it by accident and wanted to uncheck it before things were really configured. It seems to me the simple answer is to disallow unchecking when the account exists in the tax table, i.e. has already been configured as a tax account. Best Wishes, Chris Travers -- 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 -- 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
[Ledger-smb-devel] Tax account creation: how to 'detect' tax accounts?
In an attempt to fix bug 3321964, I'm running into the situation that our model doesn't seem to be able to detect which accounts are tax accounts. I'm inclined to add a checkmark to the accounts table to that purpose -- including a checkmark in the column where also 'contra' and 'recon' are located. The problem I'm seeing is that the accounts creation functions don't add records to the 'tax' table. But how would they know how to set up the records in that table without integrating the System-Taxes screen into the account creation screen? In other words: I think there should be a separate 'I'm a tax account' boolean which indicates inclusion into the System-Taxes screen and the records in the tax table which describe how taxes can and should be calculated. My line of reasoning also finds its roots in the fact that the account link checkmarks can be removed, but that probably does not invalidate the nature of the account. Or should that mean the account shouldn't be shown in System-Taxes screen? 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
Re: [Ledger-smb-devel] Tax account creation: how to 'detect' tax accounts?
Hi Chris, On Sun, Jun 19, 2011 at 3:38 PM, Chris Travers chris.trav...@gmail.com wrote: On Sun, Jun 19, 2011 at 5:59 AM, Erik Huelsmann ehu...@gmail.com wrote: In an attempt to fix bug 3321964, I'm running into the situation that our model doesn't seem to be able to detect which accounts are tax accounts. I'm inclined to add a checkmark to the accounts table to that purpose -- including a checkmark in the column where also 'contra' and 'recon' are located. The problem I'm seeing is that the accounts creation functions don't add records to the 'tax' table. But how would they know how to set up the records in that table without integrating the System-Taxes screen into the account creation screen? select ... from account where id in (select account_id from account_link where description like '%_tax'); As we were discussing on gTalk, I'm repeating myself here for others: 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. 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]. 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
Re: [Ledger-smb-devel] Tax account creation: how to 'detect' tax accounts?
On Sun, Jun 19, 2011 at 2: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. 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. So I'll ask the question: is there any conceivable reason why someone might want to uncheck a tax account? Export sales. Years ago I looked at buying something while I was in Europe. Local purchasers paid 18% tax but because I was shipping the item directly out of country the tax was 0%. Darald The only one I can think of, is someone wanting to temporarily prevent that tax from being calculated or included. 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. Luke -- 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 -- 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
Re: [Ledger-smb-devel] Tax account creation: how to 'detect' tax accounts?
Hi Darald, On Sun, Jun 19, 2011 at 11:47 PM, o1bigtenor o1bigte...@gmail.com wrote: On Sun, Jun 19, 2011 at 2:56 PM, Luke account...@lists.tacticus.com wrote: On Sun, 19 Jun 2011, Erik Huelsmann wrote: So I'll ask the question: is there any conceivable reason why someone might want to uncheck a tax account? Export sales. Years ago I looked at buying something while I was in Europe. Local purchasers paid 18% tax but because I was shipping the item directly out of country the tax was 0%. Darald Since I'm only recently on the LedgerSMB team, I'll have to take your word for it, but I'd thought the answer would be to create a customer -- presumably the one in the other country - which doesn't have the 'tax applicable' check marks in the customer screen. I was assuming so far that that prevented tax from being calculated. Isn't that the solution? If not, what's the effect of unchecking the tax account in the customer screen? 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
Re: [Ledger-smb-devel] Tax account creation: how to 'detect' tax accounts?
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 PL 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
Re: [Ledger-smb-devel] Tax account creation: how to 'detect' tax accounts?
On Sun, Jun 19, 2011 at 2:47 PM, o1bigtenor o1bigte...@gmail.com wrote: On Sun, Jun 19, 2011 at 2: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. 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. So I'll ask the question: is there any conceivable reason why someone might want to uncheck a tax account? Export sales. Years ago I looked at buying something while I was in Europe. Local purchasers paid 18% tax but because I was shipping the item directly out of country the tax was 0%. Different problem, one we need to address separately. Unless I am completely lost here in this discussion, I think Erik is saying that tax accounts should be marked as such on he Create/Edit Account screen. We are talking here about account-level settings. What I hear you talking about is the occasional need to uncheck or check tax settings on an invoice level. There are a few use cases where this is required and I think we need to look at allowing this at some point. For example, in addition to export sales, consider sales tax in most US states is not chargeable for goods purchased for retail. You give a declaration to the business and they don't charge you sales tax on transactions you identify as goods for resale. They are still required to charge taxes on goods that you don't declare as such. Like export purchase, this is a transaction-level issue not an issue of whether an account is a tax account or not. Thinking about this some more, wondering if we should create a branch of the Simple module which would detect the shipto country, compare against the Default Country setting, and only charge taxes on things delivered to the default country. That might be less error prone than manually checking/unchecking boxes on the invoice screen though it wouldn't avoid the goods for resale issue above since that's a matter of customer declaration at time of purchase. Best Wishes, Chris Travers -- 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
Re: [Ledger-smb-devel] Tax account creation: how to 'detect' tax accounts?
On Sun, 19 Jun 2011, Roderick A. Anderson wrote: So I'll ask the question: is there any conceivable reason why someone might want to uncheck a tax account? Non-profit organizations that don't have to pay sales tax? Wouldn't they just delete the account? Or not select it as tax in the first place? Question: do zero percentage accounts still show up on invoices and such in 1.3? Luke -- 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
Re: [Ledger-smb-devel] Tax account creation: how to 'detect' tax accounts?
On Sun, 19 Jun 2011, Chris Travers wrote: On Sun, Jun 19, 2011 at 2:47 PM, o1bigtenor o1bigte...@gmail.com wrote: On Sun, Jun 19, 2011 at 2:56 PM, Luke account...@lists.tacticus.com wrote: On Sun, 19 Jun 2011, Erik Huelsmann wrote: 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. [As a side note, I'm convinsed by Erik's arguement about stuff entering undefined/broken states if someone unchecked that flag, so I have no continuing objection to the proposal.] So I'll ask the question: is there any conceivable reason why someone might want to uncheck a tax account? Export sales. Years ago I looked at buying something while I was in Europe. Local purchasers paid 18% tax but because I was shipping the item directly out of country the tax was 0%. Different problem, one we need to address separately. Unless I am completely lost here in this discussion, I think Erik is saying that tax accounts should be marked as such on he Create/Edit Account screen. We are talking here about account-level settings. *and* that they can not subsequently be unmarked. I questioned that part. Thinking about it further, there should probably be some things that appear on the new account screen, that do not even show up on account editing screens. (Although, that screws with save as new functionality) Tax selector, account type (Inc/Exp/Cash/...). What I hear you talking about is the occasional need to uncheck or check tax settings on an invoice level. There are a few use cases where this is required and I think we need to look at allowing this at some point. For example, in addition to export sales, consider sales tax in most US states is not chargeable for goods purchased for retail. You give a declaration to the business and they don't charge you sales tax on transactions you identify as goods for resale. They Yes. I have a new client which I am setting up in LSMB, who is going to have this problem, a lot. I had thought that was something we were looking to have in 1.3, back when it was discussed 18 months or so ago. Thinking about this some more, wondering if we should create a branch of the Simple module which would detect the shipto country, compare against the Default Country setting, and only charge taxes on things delivered to the default country. That might be less error prone than manually checking/unchecking boxes on the invoice screen though it wouldn't avoid the goods for resale issue above since that's a matter of customer declaration at time of purchase. A good idea, but how would that work in places like the EU? A bunch of countries functioning in a block? I don't know anything about their tax codes, but I thought that some taxes applied across national borders there, although not outside the Union of course. Luke -- 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
