Re: Apportioning GST in the account register
Hi, Mark Sutton m...@lazo.ca writes: Hi,I guess I should comment about a solution I have imagined for some time. It has been suggested before that formula can be entered into the amount fields of the ledger. For an item with tax included, such as a bank import. I would enter something like $amount - ($amount * 5 / 105) this leaves the amount before tax in the account entry and generates an IMBALANCE-CAD entry for the input tax credit amount. For me this happens to be one or two account entries away from GST-ITC. It only does this if you commit the transaction then. If you don't commit it, and instead tab or arrow out of the line, then you'll get a new split with the tax amount and you can assign the account. This works fine, but it seems just wrong to be entering the same formula over and over again into a programmable device. One possibility would be to have this formula available from the ALT menu. Ideal would be a group a user defined formula, and the ability to place products into specific accounts. Not automated, but a step in the right direction. At this point the ALT menu has the ability to delete a transaction or the splits from a transaction . It also seems to have a the ability to create new entries other accounts. How possible is it to add the other functionality? SMOP. Patches always welcome. Cheers. Mark -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ 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: Apportioning GST in the account register
Mark, Thanks for your suggestion, but my client is not keen on that solution. They want to make life as simple as possible for their non-technical clients. Steve ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Apportioning GST in the account register
Hi,I guess I should comment about a solution I have imagined for some time. It has been suggested before that formula can be entered into the amount fields of the ledger. For an item with tax included, such as a bank import. I would enter something like $amount - ($amount * 5 / 105) this leaves the amount before tax in the account entry and generates an IMBALANCE-CAD entry for the input tax credit amount. For me this happens to be one or two account entries away from GST-ITC. This works fine, but it seems just wrong to be entering the same formula over and over again into a programmable device. One possibility would be to have this formula available from the ALT menu. Ideal would be a group a user defined formula, and the ability to place products into specific accounts. Not automated, but a step in the right direction. At this point the ALT menu has the ability to delete a transaction or the splits from a transaction . It also seems to have a the ability to create new entries other accounts. How possible is it to add the other functionality? Cheers. Mark ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Apportioning GST in the account register
Just to expand on the previous message... Exactly as in your example, in Australia (and other countries around the world) GST (or VAT) has to be calculated on the basis of the various components - some taxable, others not taxable - for every transaction. 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. The need for automation arises because even small businesses have large numbers of transactions and the manual entry of the components (including GST) for each and every transaction is very time consuming. The problem is exacerbated (in Australia, at least) because invoices often only reflect the total price paid for each component and a flag if that price includes GST. To work out the GST component, we have to divide the gross price by 11 (eleven) - again a time consuming process with potential for data entry errors all along the way. Even if the changes to GnuCash are complex and expensive, my clients are prepared to look at any quote or estimate for the GnuCash improvement because it is an extensive problem in Australia - and probably around the world. Steve ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Apportioning GST in the account register
The way the current Gnucash customer invoice interface works with options for Taxable? and Tax Included? is perfect for their needs, as long as it can be implemented in a normal cheque account register. Some transactions would be taxable and others not. I am happy to do the development work and release it under GPL, but just need some assistance in homing in on the appropriate source files. I really do not comprehend how people think this could be automated. If I walk into Wilsons (a local independent department store, does carry high end stuff at excellent prices for the quality) and purchase a number of items and pay at checkout with one check: 1) Eight pairs of slacks at $40 - $320 (not taxable in this jurisdiction) 2) A fancy new winter coat with fur trimmed collar at $310 TAXABLE -- although clothing isn't taxable in this jurisdiction luxury clothing is; any items costing over X dollars. I am saying X because can't expect another jurisdiction that has this policy to be using the same X. Note that the slacks weren't' taxed because in this jurisdiction that X is on a per item basis. 3) A set of pots and pans $95 --- $95 taxable 4) A small box of buns to be taken home and eaten there --- $4 not taxed, food 5) A small box of buns $4 to be eaten along with our coffee $2 so $6 and this is subject to the tax as meals and is treated different than food. Look, I can enter this manually into gnucash from the receipt which will spell out the amount that was tax. But I can't imagine gnucash having code to automate for THIS specific jurisdiction, especially if you consider that if this were at a store 20 miles to the North or 30 miles to the NE (as the crow flies) or 50 miles to the W or 60 miles to the S would have been in different jurisdictions with different sales tax rules (no sales tax in the one 30 miles to the NE). Michael ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Apportioning GST in the account register
I really do not comprehend how people think this could be automated. The problem is not how to automate tax rules for differing tax jurisdictions, rather it is to give one the option of apportioning tax (GST) on various components of a bank account transaction, just as is currently the case when generating an invoice. In Australia (and other countries around the world) GST (or VAT) has to be calculated on the basis of the various components of each transaction - some taxable, others not taxable. That is fine if companies are on full invoicing systems, but smaller businesses need to be able to split their bank account transactions also. Steve ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Apportioning GST in the account register
Hi John, At the moment they are not using Gnucash because of this limitation. The way the current Gnucash customer invoice interface works with options for Taxable? and Tax Included? is perfect for their needs, as long as it can be implemented in a normal cheque account register. Some transactions would be taxable and others not. I am happy to do the development work and release it under GPL, but just need some assistance in homing in on the appropriate source files. Steve PERTH ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Apportioning GST in the account register
Hi Steve, I was going to ask the same question and would be happy to contribute to some paid development. How are you doing GST in the meantime? At the moment a crude approach would be to just calculate 10% on all GST categories. or I am also thinking of writing a filter that will look at the original imported QIF file and then based on the PAYEE line Auto Allocate a category and split out the tax.. Then Import THIS filtered file into Gnucash or QUICKEN (my current program). Sounds like a lot of work BUT its a lot less than coin git manually now. John SYDNEY -- View this message in context: http://gnucash.1415818.n4.nabble.com/Apportioning-GST-in-the-account-register-tp4672036p4672053.html Sent from the GnuCash - Dev mailing list archive at Nabble.com. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Apportioning GST in the account register
Good day, I have a client who wants to use Gnucash as a cashbook and be able to apportion GST on certain entries in the cheque account register. The idea is to have some options for Taxable? and Tax Included? like the Invoice Entry window has and then automatically apportion GST to the appropriate account if the transaction is taxable. I have spent numerous hours digging around the Gnucash source, only to realise that it's a lot more complex than I thought. So, my questions are as follows: 1. Can anyone give me a clue as to which source files I should be looking at? 2. If I can't come right with this myself, would anyone be interested in paid development work to implement this? The results of the work would be made available under GPL again. Kind regards, Steve ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
