[Ledger-smb-devel] Taxation: 1.3 regresses wrt 1.2 according to the manual?
Hi Chris, all, John Locke said he didn't get how the taxation system is supposed to work in 1.3. Reading the manual, I see that the 1.3 taxation system is a stripped down version of 1.2. Is that still the case? If so, I think we should make that very clear before releasing 1.3, if we're not going to do anything about it. Sure: we can address that as an add-on. I'm fine with that, but maybe that add-on should come with a release date if it's not available when we do 1.3, assuming the extended tax system adds real value over the 'simple' version that comes with 1.3 already. Does the manual document the extended or the simple version? Anyway, from reading the manual, I'm not getting the idea 1.3 matches the documentation :-) What's there to be done? 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
[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] Updating 1.3 RFC and small bugs
On 06/18/2011 04:23 PM, Chris Travers wrote:
On Sat, Jun 18, 2011 at 12:55 PM, Erik Huelsmann ehu...@gmail.com wrote:
Hi John,
On Sat, Jun 18, 2011 at 8:10 PM, John Locke m...@freelock.com wrote:
Hi,
After a couple weeks away from bookkeeping, doing some catchup now. Just
pulled down the latest trunk, and merged them in.
I see the new sql/upgrade directory, which strikes me as a great direction
to go. I like the naming of sql update scripts with svn id, and I'd like to
take it one step further: keep a value in the defaults table for the
latest db updates.
I just did the following:
INSERT INTO defaults VALUES ('schema_version', '3273');
... since that looks like the largest svn id with a change under sql.
As the first part of scripting updates, it would be really great to have
each schema change dropped into an update sql script in sql/upgrade, with
the svn id in the file name. And part of the script would be updating the
schema_version in defaults (which should get initially set in
Pg-database.sql).
I just spent 2 hours applying schema updates... would be so much easier to
just import a few sql files. (granted, much of that was fixing underlying
data issues uncovered by adding unique keys...).
Very nice idea. I wonder how to take this further: Chris seems to have
started with that directory, but I have no idea how we should maintain
it, or if there's anything we could do to make it easy or enforced to
update the updates/ directory too.
My thinking is that any time DDL changes unless it is just the
internals of a function (where the sl file can be reloaded), we should
have a file to accommodate that change.Every biweekly release can
also have a psql script which loads changed function definitions since
last snapshot. I think the convention should be [svn
revi]_description.sql
This much sounds good... but there's still the issue of knowing which
sql files need to get reloaded. This is where I think we need a schema
version, and some sort of convention for knowing when an sql file gets
changed (other than timestamps/commit logs).
I can think of two different reasonable approaches:
1. Parseable change log that can be used by an update function.
2. Index file of schema id of the last change to each sql file.
First off, the schema version -- I propose we make it related to svn id,
without requiring it to be exact. Committers will need to be careful
when updating trunk to make sure they increase the number and include
all changes -- which is where commit id makes sense. But in practice, in
update scripts, I think the main thing to care about is whether the
schema version is bigger than the one currently in the database.
For approach 1, I would see writing update functions similar to Drupal,
with the schema id in the name. The function could load any updated sql
files, as well as insert new ones. Some controller function can parse
the file, find all update functions bigger than the current schema file,
and execute them.
For approach 2, I see creating a hash of all the sql files, each with
the most recent schema version containing a change to that file. Then
our update function could just look for sql files with a bigger schema
version and reload them.
Thoughts?
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
[Ledger-smb-devel] New Development Snapshot 1.3-20110619 out
This corrects a few database schema and role permissions issues as well as fixes for the menu, order entry, etc. The menu system also now respects access control lists. 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
[Ledger-smb-devel] Bug/Patch: email form not populated with emails from account
When using the Email button to send an invoice to a customer, the
email form does not populate the email/cc/bcc fields from the customer
account.
Here's at least a partial patch to accomplish this (partial because I'm
not sure if I have all of the areas I patched to make this happen -- it
does work correctly on my system.). This patch is against svn #3281, let
me know if I need to re-roll against an updated trunk.
Cheers,
John Locke
http://freelock.com
diff --git LedgerSMB/Form.pm LedgerSMB/Form.pm
index 21a6cac..fec0301 100644
--- LedgerSMB/Form.pm
+++ LedgerSMB/Form.pm
@@ -2432,6 +2431,18 @@ sub create_links {
$self-{queued} .= $ref-{formname} . $ref-{spoolfile}
if $ref-{spoolfile};
}
+
+# get email accounts
+$query = qq|
+SELECT * FROM eca__list_contacts(?)|;
+$sth = $dbh-prepare($query);
+$sth-execute( $self-{entity_id} ) || $self-dberror($query);
+
+my $ctype;
+while ( $ref = $sth-fetchrow_hashref('NAME_lc') ) {
+$ctype = lc $ref-{class};
+$self-{$ctype} .= $ref-{contact} ;
+}
$sth-finish;
for (qw(printed emailed queued)) { $self-{$_} =~ s/ +$//g }
@@ -2802,7 +2813,7 @@ sub update_status {
$sth = $dbh-prepare($query);
$sth-execute( $self-{id}, $printed, $emailed, $spoolfile,
-$self-{formname} );
+$self-{formname} ) || $self-dberror($query);
$sth-finish;
}
@@ -2829,7 +2840,7 @@ sub save_status {
WHERE trans_id = ?|;
my $sth = $dbh-prepare($query);
-$sth-execute( $self-{id} );
+$sth-execute( $self-{id} ) || $self-dberror($query);
$sth-finish;
my %queued;
diff --git LedgerSMB/Mailer.pm LedgerSMB/Mailer.pm
index 29c8bd4..f294575 100644
--- LedgerSMB/Mailer.pm
+++ LedgerSMB/Mailer.pm
@@ -160,11 +160,11 @@ sub attach {
my %args = @_;
carp Message not prepared unless ref $self-{_message};
- if (defined $args{filename}) {
- if (!$args{filename}){
+ if (defined $args{file}) {
+ if (!$args{file}){
carp Invalid filename provided;
- } elsif (!defined $args{data} and !(-f $args{filename} and -r $args{filename})){
- carp Cannot access file: $args{filename};
+ } elsif (!defined $args{data} and !(-f $args{file} and -r $args{file})){
+ carp Cannot access file: $args{file};
}
} else {
carp No attachement supplied unless defined $args{data};
diff --git LedgerSMB/Template.pm LedgerSMB/Template.pm
index d368356..03e2182 100755
--- LedgerSMB/Template.pm
+++ LedgerSMB/Template.pm
@@ -270,7 +270,7 @@ sub render {
my $post = $format-can('postprocess')-($self);
if (!$self-{'noauto'}) {
# Clean up
- $self-output;
+ $self-output(%$vars);
if ($self-{rendered}) {
unlink($self-{rendered}) or
throw Error::Simple 'Unable to delete output file';
@@ -361,7 +361,7 @@ sub _email_output {
my @mailmime;
if (!$self-{rendered} and !$args-{attach}) {
$args-{message} .= $self-{output};
- @mailmime = ('contenttype', $self-{mimeytype});
+ @mailmime = ('contenttype', $self-{mimetype});
}
# User default for email from
--
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] Enhancement/Patch: Show payee in reconciliation
Hi. I don't see any reason this would require re-rolling at present. I am reviewing this and wondering about a couple of changes. For example if we are reconciling against both ar and ap activity, we might want to generalize the column label. And then, would it make sense to include the GL description as equivalent as we often do in the GL reports. 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, 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] Enhancement/Patch: Show payee in reconciliation
\Ok. I see I misread the patch. The GL issue is there already. I am thinking of changing the column header to description instead of payee. Any objection there? 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
