Hi Elliot,
Am Montag, 20. September 2010 um 05:25:38 schrieb ...:
> I haven't been able to build 2.3.15 so excuse me if this has been
> accomplished already, but in using the invoice system, the find customer
> function does not offer a browse option. You must be able to reasonably
> guess the na
Hi,
Quoting Adolf Szabo :
Hello,
First: gnucash is an excellent piece of program, it really rocks.
However its main weakness is the lack of simple export/import
functionality in tab separated format for loading from/to excel
(gnumeric). I know I can export as a report to html and load to ex
Derek Atkins wrote:
>
> Hi!
>
> channel16 writes:
>
>> Some online quotes are measured in different unit, for example, cent
>> instead
>> of pound, or stock price in 100 shares instead of 1 share as on Chinese
>> open-end mutual funds market. In KMyMoney, the retrieved quotes can be
>> conver
Hi!
channel16 writes:
> Some online quotes are measured in different unit, for example, cent instead
> of pound, or stock price in 100 shares instead of 1 share as on Chinese
> open-end mutual funds market. In KMyMoney, the retrieved quotes can be
> converted into correct form by an
> http://km
Thilo Pfennig wrote:
Maybe this is a misunderstanding but what I mean is that if I make an
entry into the account "bank" I think this should still be visible,
because only if it wont there would be an error. I think oen should
distinct the real bank account and the bank account in GnuCash. Sure
my two cents
I think it would be wise to collect a precise definition of the formal
requirements before making any design decisions.
ABSOLUTELY -- determining requirements is the first step in design.
How about collecting translations of relevant sections of the actual laws in
the wiki, to
Bastiaan Veelo wrote:
> I think it would be wise to collect a precise definition of the formal
> requirements before making any design decisions. How about collecting
> translations of relevant sections of the actual laws in the wiki, to
> find the common denominator? This bit should be provided
Derek Atkins wrote:
> Perhaps this should get tied into the book closing clode? When you
> close the books on a period, all the transactions in that period become
> uneditable? We DO have the ability to mark a transaction specifically
> as read-only. It wouldn't be too hard to also mark the txn
Am Sat, 16 Feb 2008 16:52:51 +0200
schrieb Graham Leggett <[EMAIL PROTECTED]>:
> This isn't true - each entry can have more than two ends in the form
> of splits, the only requirement is that all the splits add up to zero.
ACK, I should rather have written "at least two ends".
> Gnucash isn't t
Perhaps this should get tied into the book closing clode? When you
close the books on a period, all the transactions in that period become
uneditable? We DO have the ability to mark a transaction specifically
as read-only. It wouldn't be too hard to also mark the txns as read-only
as we process
Hi,
I'll just chime in with some of my personal findings and observations. Most of
this based on my personal experience and may not be valid for everyone. But I
thought different insights might be useful to get a complete picture.
On Saturday 16 February 2008, Graham Leggett wrote:
> An example
Thilo Pfennig wrote:
I think from the acounting perspective every entry consists on som
field like the date, the accounts, some text,... I also dont think a
mix of inalterable accounts and alterable accounts makes much sense
because every entry has two ends, so if one end is inalterable the
othe
Christian Stimming wrote:
Makes sense, but do you have any ideas how such a per-account setting can be
implemented in the GUI? Currently, all per-account settings can be set in
the "Edit Account" dialog. However, a setting "Make this an inalterable
account" shouldn't be allowed to be disabled
Am Sat, 16 Feb 2008 09:18:03 +0100
schrieb Christian Stimming <[EMAIL PROTECTED]>:
> Makes sense, but do you have any ideas how such a per-account setting
> can be implemented in the GUI? Currently, all per-account settings
> can be set in the "Edit Account" dialog. However, a setting "Make
> this
Am Freitag, 15. Februar 2008 23:50 schrieb Graham Leggett:
> > a gnucash mode of operation
> > where the user can not edit older transactions anymore
>
> You would definitely want to set this per account, because some accounts
> in gnucash are authoritative (eg accounts dealing with the issuing of
Christian Stimming wrote:
Some German business users brought up a "feature" request that sounds a bit
weird for a programmer: They asked for a gnucash mode of operation where the
user can not edit older transactions anymore!
Makes perfect sense - wearing my programmer hat on financial systems
Am Fri, 15 Feb 2008 21:43:25 +0100
schrieb Christian Stimming <[EMAIL PROTECTED]>:
> I'm still not completely sure how the actual implementation would
> look like.
I think the best way would be not to select the feature but that by
selecting some account templates you will get that.
If anybody
On Fri, 2008-02-15 at 21:43 +0100, Christian Stimming wrote:
> Some German business users brought up a "feature" request that sounds a bit
> weird for a programmer: They asked for a gnucash mode of operation where the
> user can not edit older transactions anymore!
This is not just important fo
Mike or Penny Novack <[EMAIL PROTECTED]> writes:
> Oh dear, making me sorry I ever brought the issue up. Look, I'm not an
> accountant but have worked on systems that have to record billings and
> payments.
>
> Yes, some businesses do put "suspense" money into a separate bank
> account (asset side
Dan Widyono <[EMAIL PROTECTED]> writes:
>> "Suspense" accounts are a user thing. GnuCash doesn't care, and
>> indeed shouldn't care. You can Process Payment into a Suspense
>> Account just as easily as you can Process Payment into a Checking
>> Account.
>
> Is it useful to allow aliases for Acco
>>"Suspense" accounts are a user thing. GnuCash doesn't care, and
>>indeed shouldn't care. You can Process Payment into a Suspense
>>Account just as easily as you can Process Payment into a Checking
>>Account.
>>
>>
Is it useful to allow aliases for Account Types? Or to add a Suspense
type
> "Suspense" accounts are a user thing. GnuCash doesn't care, and
> indeed shouldn't care. You can Process Payment into a Suspense
> Account just as easily as you can Process Payment into a Checking
> Account.
Is it useful to allow aliases for Account Types? Or to add a Suspense type
which is j
Hi,
I'm sure you meant this in a constructive way, but even after
reading this over several times over a couple days it still
comes across as condescending. I'm SURE you didn't mean it that
way, but honestly, I (and most of the GnuCash developers) have
a lot of experience in software development.
>
>
>
>Doing multiple non-consecutive invoices for the payment process would
>be arbitrarily complex. At that point the real answer is a real
>solution to http://bugzilla.gnome.org/show_bug.cgi?id=108570
>
>In my business experience this disputing an invoice is extremely
>rare, so I dont think tha
"John Z. Bohach" <[EMAIL PROTECTED]> writes:
> Yes, a drop down list for all that stuff would be great, like the combo
> box idea, but for invoices, keep in mind it would still be nice to
> select multiple non-sequential ones, hopefully the combo-box allows
> that.
Doing multiple non-consecuti
On Thursday 09 August 2007 06:35:45 pm Josh Sled wrote:
> "John Z. Bohach" <[EMAIL PROTECTED]> writes:
> > But documentation enhancements aside, I think others have also
> > expressed an interest in not always having to do a 'find ...'
> > {invoice,customer,etc.} and just rather have a drop down li
"John Z. Bohach" <[EMAIL PROTECTED]> writes:
> But documentation enhancements aside, I think others have also expressed
> an interest in not always having to do a 'find ...'
> {invoice,customer,etc.} and just rather have a drop down list show
> everything for that category, but that's getting of
On Thursday 09 August 2007 04:29:33 pm Nathan Buchanan wrote:
> Hi John,
>
> On 8/9/07, John Z. Bohach <[EMAIL PROTECTED]> wrote:
> > On Thursday 09 August 2007 12:23:54 pm Derek Atkins wrote:
> > > Um, gnucash has ALWAYS supported this. It will pay the invoices
> > > in FIFO order. If you select
John Z. Bohach wrote:
> On Thursday 09 August 2007 12:23:54 pm Derek Atkins wrote:
>> Um, gnucash has ALWAYS supported this. It will pay the invoices
>> in FIFO order. If you select an invoice in the process payment
>> dialog (you dont have to! it's completely optional) then it puts
>> that invoi
Hi John,
On 8/9/07, John Z. Bohach <[EMAIL PROTECTED]> wrote:
>
> On Thursday 09 August 2007 12:23:54 pm Derek Atkins wrote:
> > Um, gnucash has ALWAYS supported this. It will pay the invoices
> > in FIFO order. If you select an invoice in the process payment
> > dialog (you dont have to! it's c
On Thursday 09 August 2007 12:23:54 pm Derek Atkins wrote:
> Um, gnucash has ALWAYS supported this. It will pay the invoices
> in FIFO order. If you select an invoice in the process payment
> dialog (you dont have to! it's completely optional) then it puts
> that invoice at the front of the FIFO,
Um, gnucash has ALWAYS supported this. It will pay the invoices
in FIFO order. If you select an invoice in the process payment
dialog (you dont have to! it's completely optional) then it puts
that invoice at the front of the FIFO, but any overpayment will
then spill over to the next one in the li
On Fri, 2005-08-19 at 15:34 -0700, Karl Hegbloom wrote:
> But if I enter the transaction now, even if it is post-dated, won't that
> affect the displayed account balance? That would make it difficult to
Both the present and future balances are displayed.
> I will need to spend a lot of time lea
On Fri, 2005-08-19 at 16:24 -0400, Josh Sled wrote:
> On Fri, 2005-08-19 at 12:48 -0700, Karl Hegbloom wrote:
>
> > Perhaps a special feature for posting a DDA could schedule the repayment
> > just as the bank does, to have it happen right after posting the
> > paycheck? A dialog could take the i
On Fri, 2005-08-19 at 12:48 -0700, Karl Hegbloom wrote:
> Perhaps a special feature for posting a DDA could schedule the repayment
> just as the bank does, to have it happen right after posting the
> paycheck? A dialog could take the initial information, like the amount
Could you simply create b
On 7/20/2004 9:03 AM, I believe that Hoffmeis wrote:
There is a really nice feature in Microsoft Money, which I use all the
time: forcast cash flow. This feature really makes it easy to plan future
investments or to create saving plans for recurring bills. As much as I
like to change away from Mone
This sounds like a Scheduled Transaction, which is being worked on in
the CVS version of Gnucash.
-derek
Jeff Warnica <[EMAIL PROTECTED]> writes:
> Hi all..
>
> I dont know where this idea fits in the grand scheme of things, but Ive
> come up with what would definitly help me, and probabaly
A patch to do this would certainly be accepted. (hint hint)
-derek
A Guy Called Tyketto <[EMAIL PROTECTED]> writes:
> On Mon, Dec 17, 2001 at 03:52:15AM -0800, Dave Peticolas wrote:
> > 1.6.5 - 16 December 2001
> > o Euro conversion druid
> > o Updated or new translations fo
Alan Orndorff writes:
> Not sure what other people will think, BUT...
>
> A while ago I asked if it would be possible to have a Quicken
> feature added to Gnucash. Basically, if you schedule transactions
> into the future, Gnucash will show the future balance and not
> the current balance. Quic
Dave Peticolas wrote:
> In the meantime, are you aware of the keyboard accelerators
> for entering dates in the register? They are explained under
> the manual pages under the link 'Date Input'.
I looked this up in the help from 1.3.7, and I clicked on the link `keyboard
shortcuts' or whatever i
> I'd like to request a feature - which I hope will be simple to add.
>
> I usually enter transactions directly into the register, rather than
> using the 'transaction' window. I find it much quicker. However, I would
> like to be able to access the convenience of the calendar widget for
> enteri
41 matches
Mail list logo
