Ah, yes, sorry.  The account balance reported when making the transfer is the current balance, which is more than is available for the date of the actual transfer.  So yes, the balance would become negative for the transfer date.

Thx

In my case the result would not be negative.  To be specific, the amount in the source cash account is 184.60, the requested transfer amount is 100.00, and the error message states a limit of 83.06.  Where it gets this 83.06 value from is a complete mystery to me.

Could this be a bug?  I'm on v2.3.7.  If so, maybe somebody can point me to the right area of code to fudge/fix this issue?

I'm just trying to transfer money from one account to another.  Pretty straight forward, but then I get this error:

  The total bank amount exceeds allowed limit (#) for source account.

I've never had this problem before and I cannot find any setting anywhere that fixes limits specific to the account at hand.  Even in the database I see no field that could do this for the bank account table. 

Where is this being set?  How do I change it?

It seems there is no mechanism for recording old tax values.  I noticed this when I changed the Provincial Sales Tax (PST) value for 2012.  Then when I viewed OLD invoices, the new value was being used so the invoice no longer balances out.  So apparently, tax rates can only be set to a global rate.

So far, the problem seems only visual (such as viewing old invoices). Could this rate update have any adverse affects when making reports for last year?

It would be great if we could assign dates to tax values, much the same way exchange rates have dates.  I saw a suggestion on a different thread to create different tax groups for different dates.  But this would be quite convoluted and I don't really see it as a legitimate work-around. It would require admin of every customer (updating applicable tax) each time the tax changes.  For those with hundreds of customer, this seems out of the question. Furthermore, in Canada, where we have a tax for almost every province, changes happen often and the burden would be great.

Anybody?

...I'm under the impression that if I want to extend core classes I should just do so in the original code.  That there is no extension framework for extending core functionality.  Is this true?

Just a little confused after reading the description of the FA extensions framework (https://frontaccounting.com/fawiki/index.php?n=Devel.Extensions).  Could someone clarify how the desired modification described below will fit into the extension framework?

I am not looking to add a new menu option or tab, but simply extend existing core functionality.  Specifically, after a purchase order is processed/received I would like to add an additional call to a new function.  Shouldn't matter what this new function does, but in my case it will be using cURL to update 3rd party s/w.

Will a mod like this (true class extension) fit into the FA extension framework and, if so, which one (plugin or module)? Or should I just modify the appropriate core class directly and track changes via source control (SVN, CVS, etc.)?

7

(3 replies, posted in Setup)

Ok, thanks.  Will look forward to 2.4.

Thanks for the replies but these suggestions don't really help in this case as I'm trying to account for a fixed/absolute discount not a percentage discount (ie. $10 off, not 10% off).  FA already has various mechanisms in place for percentage discounts, whether it be applied to an individual item in the invoice or applied to a Sales Type (ie. Retail, Wholesale, etc.).  However, it doesn't make sense to create new Sales Types every time there is a fixed/abs discount as this would eventually clutter the Sales Types with hundreds of entries dedicated to mimicking the fixed value of a single order.  And for orders with dozens of products, it also doesn't make sense to fudge all the value to reduce the total cost by some fixed amount.  Either case would require a lot of unnecessary overhead.

Unless using charges/services items with -'ve amounts will lead to some sort of critical failure, I think this is a much better work-around.  But, none-the-less a work-around.

Just my 2 cents, I think proper support for such discounts would be a valuable addition and, with support for POS now available, I think it's also a feature that will become more in demand.

After looking around at different posts and exploring the various setup options, I get the feeling it is not possible to apply the group tax applicable to an order to the shipping costs.  That is, if the group tax for an order is 5%, I want that same 5% to apply to the shipping costs as well.

As far as I can tell, this makes the software incompatible with typical sales invoices in Canada where the tax varies from province to province and also (often) applies to shipping costs.  Having just one global shipping tax value does not suffice.

I guess I will have to add a new charge item for shipping costs and add this item to each order to account for shipping.  This seems like a valid work-around.

Has anybody else had to deal with this and have a different solution?

joe wrote:

The prices cannot be entered with negative amounts.
Consider using a PriceList with the reduced prices instead.
/Joe

Why do you say 'cannot'?  This is what I'm doing now and the journal entries are as expected.  That is, positive prices credit the sales account and negative prices debit it.  And the total on the invoice is correct also.  Is see no issue with doing this.  Is something going to screw up internally by doing this that I'm not aware of?

And what are you referring to by 'PriceList'?  Is this a feature, or do you mean adjust each item price to make-up for the difference created by the discount, as suggested by rodw's post?

Are fixed/absolute discount amounts possible on a sales order/invoice?  That is, a discount amount not related to any particular product.  This is similar to the question posed in the thread https://frontaccounting.com/punbb/viewtopic.php?id=1277, except I'm finding that negative prices ARE allowed (with a warning message), whereas in that thread it was stated that this wasn't possible (I assume the code was changed since then).

My current solution is to enter a charge item with a negative price.  Is this the accepted solution/work-around or is there a better way?

When I configure a new POS option under setup, I never see anyway to select it.  Direct Invoices appear hard-coded to select the default entry (Petty Cash).  Am I missing something here?  I'd like to be able to enter a direct invoice that goes to a non-cash account, while still maintaining the option to use petty cash.

It's not so important to me that the shipping costs be represented in the COGS of an item, but just that the appropriate amounts are credited and debited to the inventory and COGS accounts when a sale is made, without requiring additional manual entries to the GL.  Is there any way to implement your suggestion (enter shipping costs into accounts separately from item costs) but have it happen automatically when a sales order is completed?  I wouldn't want to have to manually credit the inventory account to the COGS account every time an order comes in just to handle shipping costs.

Is there any way to associate freight costs of a supplier purchase with the COGS of items within that purchase?

For example, buy 10 items at $10 each, but shipping costs $20, so COGS should = $12 per unit.

From what I understand in a previous post (https://frontaccounting.com/punbb/viewtopic.php?id=1440) this is not possible, but want to make sure it's still the case.  And if it's not possible, can anybody explain to me what the user 'sannyferns' means in this previous post (6th post).  He apparently has a work around to the issue, but I don't quite understand it.

For me, the work around would be entering a unit cost of $12, or whatever it is next time, into FA.  But this has the disadvantage of having to predetermine the COGS outside of FA each time a suppler purchase is made, as well as loosing the ability to record purchasing prices in FA (since they are now item+S&H prices).

I noticed that when I edit journal entries, like update a memo, the existing entry is modified.  However, when I edit a Bank Payment, even just the memo, a new entry is created with a new entry number.  Although inconsistent, this doesn't bother me too much since it is only a number, however, the change also results in any attachments being dropped.  Since I attach copies of invoices to many payments, now I must re-attach the document anytime I edit and, ideally, to keep things tidy, remember to delete the old attachment which is otherwise just floating around without a real home.  This of course is worsened by the fact that is much less straight forward to attach documents under Setup (as is required after an edit) than after creating a new entry.

Would it not be possible to keep the same entry number so attachments are maintained?  Or, if not, automatically transfer the attachment to the new entry and delete the attachment record of the old?