Bug 734183
Hi All I'm having a little trouble tracking this down, (some of) the code for creating an entry with discount is shown below: entry = gncEntryCreate (book); gncEntryBeginEdit(entry); // More code here... gnc_exp_parser_parse (discount, n, NULL); gncEntrySetInvDiscount (entry, n); gncEntrySetInvDiscountType (entry, text2disc_type (disc_type)); gncEntrySetInvDiscountHow (entry, text2disc_how (disc_how)); gncEntryCommitEdit(entry); n = gncEntryGetDocDiscountValue (entry, FALSE, TRUE, FALSE); DEBUG( Discount Value: %.2f\n,gnc_numeric_to_double(n)); gncInvoiceAddEntry (invoice, entry); Having set the Discount, How and Type, the DEBUG line outputs - Discount Value: 0.00 it should be the actual calculated discount. Why isn't the discount being set. calculated? Is there a step I've missed? Looking through gnc_entry_ledger_save_cells(...) in gncEntryLedgerModel.c I can't see anything else that needs to be done to set the required values. Code is in: src/plugins/bi_import/dialoc-bi-import.c Mike -- Anti NSA? Use PGP. http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x00CDB13500D7AB53 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Apportioning GST in the account register
Steven Patrick wrote: The GnuCash invoicing process does this automatically for larger businesses, but many smaller businesses use only cash book records and need to be able to automatically calculate and record GST in bank account transactions. Because it is already being done in the invoicing process, it would seem logical it can be done in the bank account process. Well let me put my analyst hat on to see what additional problems might be there. Not bank account. What might be needed here is an account type designation (for accounts otherwise simply assets) which for the moment I will call GST figuring accounts. Would have to be treated as asset accounts for balance sheet purposes. In other words, might have to be more general than bank account. I don't know how your small business or organization does it but the organizations I keep books for do not necessarily make daily deposits at the bank. So there would be an undeposited cash account used because it is possible that the payments were received in one accounting period but deposited in another maybe your country is different, but over here its when the money gets to you, not when you get around to depositing it, that counts for cash basis accounting However I really think you overestimate the ease for which this can be easily automated, possibly because sales tax computations are much simply in your jurisdiction than in some of the ones with which I am familiar. For example, in MA assuming the business is a small supermarket 1) The bottle of laundry detergent is taxed. 2) The small box of donuts to be taken home is not. 3) The small box of donuts and coffee eaten in the store while going over the sale list are taxed, but a different rate than the laundry detergent. In other words, over here in some jurisdictions things aren't simply taxed or not taxed, but possibly taxed at different rates. Might I suggest something? Maybe what is missing isn't this feature you see as missing but an entire point of sales system and it is the output of that system which enters the accounting package -- also typically feeds the inventory system, also missing. Note that these are not normally PART of the accounting package. Some commercial products are a complete SET of packages, accounting, inventory, point of sales, etc. In cases like this it is a business decision of the vendor of such packages which jurisdictions to support and which to ignore (too small to be enough potential customers to compensate us for tailoring a version for their specific needs). Michael D Novack ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Bug 734183
On Wednesday 06 August 2014 10:25:12 Mike Evans wrote:
Hi All
I'm having a little trouble tracking this down, (some of) the code for
creating an entry with discount is shown below:
entry = gncEntryCreate (book);
gncEntryBeginEdit(entry);
// More code here...
gnc_exp_parser_parse (discount, n, NULL);
gncEntrySetInvDiscount (entry, n);
gncEntrySetInvDiscountType (entry, text2disc_type
(disc_type)); gncEntrySetInvDiscountHow (entry, text2disc_how
(disc_how)); gncEntryCommitEdit(entry);
n = gncEntryGetDocDiscountValue (entry, FALSE, TRUE, FALSE);
DEBUG( Discount Value: %.2f\n,gnc_numeric_to_double(n));
gncInvoiceAddEntry (invoice, entry);
Having set the Discount, How and Type, the DEBUG line outputs -
Discount Value: 0.00 it should be the actual calculated discount.
Why isn't the discount being set. calculated? Is there a step I've
missed?
Looking through gnc_entry_ledger_save_cells(...) in
gncEntryLedgerModel.c I can't see anything else that needs to be done
to set the required values.
Code is in: src/plugins/bi_import/dialoc-bi-import.c
Mike
Mike,
I have ran the the master branch as of July 4 through gdb. It doesn't have all
the code exactly
as you pasted in your mail, but it's similar enough IMO.
The line
gnc_exp_parser_parse (discount, n, NULL);
sets n to 0 (more strictly {0, 1}, a gnc_numeric). That doesn't seem correct,
or at least not what
you are expecting since discount has a value of 25.0. Maybe you should set an
error variable
instead of NULL in that function call and check its value for more clues.
Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Bug 734183
On Wed, 06 Aug 2014 15:49:08 +0200
Geert Janssens janssens-ge...@telenet.be wrote:
On Wednesday 06 August 2014 10:25:12 Mike Evans wrote:
Hi All
I'm having a little trouble tracking this down, (some of) the code for
creating an entry with discount is shown below:
entry = gncEntryCreate (book);
gncEntryBeginEdit(entry);
// More code here...
gnc_exp_parser_parse (discount, n, NULL);
gncEntrySetInvDiscount (entry, n);
gncEntrySetInvDiscountType (entry, text2disc_type
(disc_type)); gncEntrySetInvDiscountHow (entry, text2disc_how
(disc_how)); gncEntryCommitEdit(entry);
n = gncEntryGetDocDiscountValue (entry, FALSE, TRUE, FALSE);
DEBUG( Discount Value: %.2f\n,gnc_numeric_to_double(n));
gncInvoiceAddEntry (invoice, entry);
Having set the Discount, How and Type, the DEBUG line outputs -
Discount Value: 0.00 it should be the actual calculated discount.
Why isn't the discount being set. calculated? Is there a step I've
missed?
Looking through gnc_entry_ledger_save_cells(...) in
gncEntryLedgerModel.c I can't see anything else that needs to be done
to set the required values.
Code is in: src/plugins/bi_import/dialoc-bi-import.c
Mike
Mike,
I have ran the the master branch as of July 4 through gdb. It doesn't have
all the code exactly
as you pasted in your mail, but it's similar enough IMO.
The line
gnc_exp_parser_parse (discount, n, NULL);
sets n to 0 (more strictly {0, 1}, a gnc_numeric). That doesn't seem correct,
or at least not what
you are expecting since discount has a value of 25.0. Maybe you should set
an error variable
instead of NULL in that function call and check its value for more clues.
Geert
HiGeert.
n is set to 25 using gnc_exp_parser_parse (discount, n, NULL); just after it's
set to gnc_numeric_zero (); Taking the zeroing line out doesn't change the
behaviour though.
Where discount is read from the file. When the invoice is opened after import
the 25.00 is shown in the discount column but the price hasn't been discounted,
the line total is still at original price.
The gncEntryGetDocDiscountValue () function calls the
gncEntry::gncEntryRecomputeValues() function which should set he discount to be
applied.
--
Anti NSA? Use PGP.
http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x00CDB13500D7AB53
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Bug 734183
On Wednesday 06 August 2014 16:00:21 Mike Evans wrote: HiGeert. n is set to 25 using gnc_exp_parser_parse (discount, n, NULL); just after it's set to gnc_numeric_zero (); Taking the zeroing line out doesn't change the behaviour though. Oh right. Probably this isn't working for me because my decimal separator is ,. Sorry for the false suggestion. Where discount is read from the file. When the invoice is opened after import the 25.00 is shown in the discount column but the price hasn't been discounted, the line total is still at original price. The gncEntryGetDocDiscountValue () function calls the gncEntry::gncEntryRecomputeValues() function which should set he discount to be applied. Yes, it does. As an aside This is a horribly backward way of doing things and source of various bugs. We should definitely fix this at some point. I fixed the import file for my locale and reran the debugger. The gncEntryRecomputeValues function effectively does nothing in this case because the entry has no Invoice tax table set. The recalculation only happens when there is either a bill or an invoice tax table. So that would explain why the discount is not substracted. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash c++
On Tue, Aug 5, 2014 at 2:04 PM, John Ralls jra...@ceridwen.us wrote:
Aaron,
I've pulled and begun testing your guidcpp branch. It looks good, and I
expect to merge it to master today or Thursday.
Excellent! :-)
What is the motivation for compiling everything as C++ if it's still
really C and you have to wrap everything in extern C {} to get it to
link, especially in gnome and register directories, which can't be
converted to C++?
The only extern Cs in c++-debug branch are for SCM and module entry
points, and only the latter is for more than one declaration. That comes up
to 13 functions that are declared extern C ?
The motivation is to investigate a different strategy for migrating to C++.
I was skeptical that it would work at all, but, through argument, I
couldn't come up with any solid reasons why it couldn't work, so I decided
to give it a go. The strategy is:
Step 1) Get the project to compile as C++. Step 2) add poison to remove non
c++ idioms, etc. Step 3) Make higher level changes.
And the strategy entails that these steps are followed quite strictly. So
far, I don't consider Step 1 complete, because although the project
compiles and links, it's not shippable ... perhaps not even close :-).
Like... nothing works.
To be clear, I'm just answering your question, not actually proposing this
strategy. If it goes well, it is naturally up to the development team to
adopt such a strategy.
Thanks for the response! I kept my response brief, but anyone feel free to
ask more questions. I spent the last three days or so catching up on
gnucash mailing list items (you've perhaps seen my replies, etc.), and now
I can get back to looking at the code!
In Christ,
Aaron Laws
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
gnucash c++
I tried to follow the directions at
http://wiki.gnucash.org/wiki/Contributing_to_GnuCash, but I couldn't find a
Bugzilla issue encapsulating the Great C++ Refactor. Should I create one so
there is a place to put patches?
I learned on IRC that it is generally a goal not to have C++ keywords in
the Gnucash code base, and this patch is along those ends. I think I got
all the C++11 keywords that would interfere with a C++11 compile. If this
is an inappropriate patch to submit, please let me know. After my
signature, you can find the patch prepared using `git format-patch` (as
specified in http://wiki.gnucash.org/wiki/Git#Patches). Also, I followed
the advice of http://wiki.gnucash.org/wiki/Development_Process (All
development should target the *master* branch.). Please let me know if
anything looks amiss (the amount of context, using unified diff format,
perhaps I should be attaching instead of in-line quotation, etc.). Thanks!
In Christ,
Aaron Laws
From c58457879496a26031e7a412deb429c9ef572fb9 Mon Sep 17 00:00:00 2001
From: lmat dartm...@gmail.com
Date: Wed, 23 Jul 2014 17:47:02 -0400
Subject: [PATCH] Replacing c++ reserved keywords with clean alternatives
---
src/app-utils/gnc-component-manager.h | 2 +-
src/app-utils/test/test-option-util.c | 2 +-
src/engine/gnc-commodity.c | 152
src/engine/test-core/test-engine-stuff.c| 6 +-
src/engine/test/utest-Account.c | 22 ++--
src/engine/test/utest-Transaction.c | 62 +-
src/gnome-utils/assistant-xml-encoding.c| 10 +-
src/gnome-utils/dialog-commodity.c | 96 +++
src/gnome-utils/dialog-commodity.h | 4 +-
src/gnome-utils/dialog-preferences.c| 4 +-
src/gnome-utils/dialog-reset-warnings.c | 4 +-
src/gnome-utils/dialog-totd.c | 14 +--
src/gnome-utils/gnc-amount-edit.c | 2 +-
src/gnome-utils/gnc-cell-renderer-date.c| 12 +-
src/gnome-utils/gnc-cell-renderer-popup-entry.c | 2 +-
src/gnome-utils/gnc-cell-renderer-popup.c | 16 +--
src/gnome-utils/gnc-combott.c | 14 +--
src/gnome-utils/gnc-currency-edit.c | 2 +-
src/gnome-utils/gnc-date-delta.c| 2 +-
src/gnome-utils/gnc-date-format.c | 2 +-
src/gnome-utils/gnc-dense-cal.c | 2 +-
src/gnome-utils/gnc-general-select.c| 2 +-
src/gnome-utils/gnc-period-select.c | 2 +-
src/gnome-utils/gnc-plugin.c| 32 ++---
src/gnome-utils/gnc-tree-model-commodity.c | 92 +++---
src/gnome-utils/gnc-tree-model-commodity.h | 2 +-
src/gnome-utils/gnc-tree-model-price.c | 102
src/gnome-utils/gnc-tree-model-price.h | 2 +-
src/gnome-utils/gnc-tree-view-commodity.c | 6 +-
src/gnome-utils/gnc-tree-view-price.c | 6 +-
src/gnome-utils/search-param.c | 2 +-
31 files changed, 340 insertions(+), 340 deletions(-)
diff --git a/src/app-utils/gnc-component-manager.h
b/src/app-utils/gnc-component-manager.h
index 7de280f..45fc187 100644
--- a/src/app-utils/gnc-component-manager.h
+++ b/src/app-utils/gnc-component-manager.h
@@ -104,7 +104,7 @@ typedef gboolean (*GNCComponentFindHandler) (gpointer
find_data,
*
* Return: TRUE if the callback did something
*/
-typedef gboolean (*GNCComponentHandler) (const char *class,
+typedef gboolean (*GNCComponentHandler) (const char *component_class,
gint component_id,
gpointer user_data,
gpointer iter_data);
diff --git a/src/app-utils/test/test-option-util.c
b/src/app-utils/test/test-option-util.c
index dc99f32..8fef4c0 100644
--- a/src/app-utils/test/test-option-util.c
+++ b/src/app-utils/test/test-option-util.c
@@ -41,7 +41,7 @@ typedef struct
/* Expose a mostly-private QofInstance function to load options into
* the Book.
*/
-extern KvpFrame *qof_instance_get_slots (QofInstance*);
+extern KvpFrame *qof_instance_get_slots (const QofInstance*);
static void
setup (Fixture *fixture, gconstpointer pData)
diff --git a/src/engine/gnc-commodity.c b/src/engine/gnc-commodity.c
index d5f6eb0..554cbf6 100644
--- a/src/engine/gnc-commodity.c
+++ b/src/engine/gnc-commodity.c
@@ -68,7 +68,7 @@ struct gnc_commodity_s
typedef struct CommodityPrivate
{
-gnc_commodity_namespace *namespace;
+gnc_commodity_namespace *nmspace;
char* fullname;
char* mnemonic;
@@ -592,7 +592,7 @@ reset_unique_name(CommodityPrivate *priv)
gnc_commodity_namespace *ns;
g_free(priv-unique_name);
-ns = priv-namespace;
+ns = priv-nmspace;
priv-unique_name = g_strdup_printf(%s::%s,
ns ? ns-name : ,
priv-mnemonic ? priv-mnemonic :
);
@@ -608,7 +608,7 @@ gnc_commodity_init(gnc_commodity* com)
priv =
Re: gnucash c++
On Wednesday 06 August 2014 16:16:17 Aaron Laws wrote: I tried to follow the directions at http://wiki.gnucash.org/wiki/Contributing_to_GnuCash, but I couldn't find a Bugzilla issue encapsulating the Great C++ Refactor. Should I create one so there is a place to put patches? I learned on IRC that it is generally a goal not to have C++ keywords in the Gnucash code base, and this patch is along those ends. I think I got all the C++11 keywords that would interfere with a C++11 compile. If this is an inappropriate patch to submit, please let me know. After my signature, you can find the patch prepared using `git format-patch` (as specified in http://wiki.gnucash.org/wiki/Git#Patches). Also, I followed the advice of http://wiki.gnucash.org/wiki/Development_Process (All development should target the *master* branch.). Please let me know if anything looks amiss (the amount of context, using unified diff format, perhaps I should be attaching instead of in-line quotation, etc.). Thanks! In Christ, Hi Aaron, Thank you for your patch. I haven't tested it yet but IMO the intention is correct. As for bugzilla: you can create a new bugreport and attach your patch there. Attaching it to a mailing list message risks that it gets lost in the midst of the ongoing discussions. 'git format- patch' is perfectly fine as format. As for the All development should target the *master* branch, we should change this. That's advice from the svn era. In git bugfixes should target the *maint* branch. New features and enhancements should target *master*. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash c++
On Aug 6, 2014, at 2:16 PM, Geert Janssens janssens-ge...@telenet.be wrote: On Wednesday 06 August 2014 16:16:17 Aaron Laws wrote: I tried to follow the directions at http://wiki.gnucash.org/wiki/Contributing_to_GnuCash, but I couldn't find a Bugzilla issue encapsulating the Great C++ Refactor. Should I create one so there is a place to put patches? I learned on IRC that it is generally a goal not to have C++ keywords in the Gnucash code base, and this patch is along those ends. I think I got all the C++11 keywords that would interfere with a C++11 compile. If this is an inappropriate patch to submit, please let me know. After my signature, you can find the patch prepared using `git format-patch` (as specified in http://wiki.gnucash.org/wiki/Git#Patches). Also, I followed the advice of http://wiki.gnucash.org/wiki/Development_Process (All development should target the *master* branch.). Please let me know if anything looks amiss (the amount of context, using unified diff format, perhaps I should be attaching instead of in-line quotation, etc.). Thanks! In Christ, Hi Aaron, Thank you for your patch. I haven't tested it yet but IMO the intention is correct. As for bugzilla: you can create a new bugreport and attach your patch there. Attaching it to a mailing list message risks that it gets lost in the midst of the ongoing discussions. 'git format- patch' is perfectly fine as format. As for the All development should target the *master* branch, we should change this. That's advice from the svn era. In git bugfixes should target the *maint* branch. New features and enhancements should target *master*. I clarified http://wiki.gnucash.org/wiki/Development_Process#Developing_New_Features a bit and cleared out all of the old stuff about backports and audits. I'm not quite satisfied with it, so I'll let it percolate in my head for a day or two and have another go. If someone else has some thoughts, by all means dive in. Let's not have a generic Convert GnuCash to C++ bug that will accumulate a zillion patches and a zillion comments. That will just become a headache. If you (Aaron) would rather attach the patch to a bug, make it Remove C++11/14 Keywordsor something, but I'm perfectly happy using Github pull requests for C++ if that's more convenient. I don't really see that patch as a bug-fix; it's not a problem with maint that it doesn't compile in C++. OTOH, *not* applying it to maint will make it harder to merge into master sooner than otherwise, so I'm not opposed to it either as long as it passes `make distcheck`. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
