51 Topic by paul

(4 replies, posted in Banking and General Ledger)

In my test setup, I am at the point of matching my current GL accounts to FA's accounts. First, I am looking for an account class of Equity for owner draws (sole proprietor). In the current system, my Owner Draw account is with Retained Earnings as a negative, but they are both in an Owners Equity group.

  I find Retained Earnings in FrontAccounting, but it is in a Liability group. Since I am not an accountant, am I just splitting hairs here and the end result is the same - meaning, should I just place my Owner Draw account along with FA's Retained earnings under the liability group? Or should I create an Equity group and move the Ratained Earnings to the Equity Group.

  Also, I am noticing a customer prepayment is simply going to the Accounts Receivable/Asset account. I don't find a Customer Deposit/Liability account. Is this by design? It would seem that a customer pre-payment should be recorded to a liability account since it isn't yet an asset.

  Thank you,

Go to forum: Banking and General Ledger

52 Reply by paul

(10 replies, posted in Wish List)

I wonder if I could further solve my issues by creating a new item in inventory that matches my suppliers UOM/pricing and change my currently purchased item to Manufactured Item Type. After receiving newly created item, perform an Assemble work order to convert the item into my UOM. That way I could basically enter a PO in my supplier's units and end up with our current units. Dumb idea?

  I believe a manufactured item can still be used in a BOM list.

Go to forum: Wish List

53 Reply by paul

(10 replies, posted in Wish List)

Concerning if item/supplier conversion is correct, Price column on PO does show correctly when using the base current_user.inc file, but maybe that is not an accurate comparison (because I don't fully understand the changes to that file).

Go to forum: Wish List

54 Reply by paul

(10 replies, posted in Wish List)

I just changed Pref/Decimal Places to 2 and also changed Item UOM to 2 decimal places (just in case) and that doesn't change the printed PO. I believe I have the supplier pricing/conversion correctly as the supplier Quantity Units show correctly on the PO. If I edit the PO and double my inventory units, the PO will show 2 units. Also, the Total column on the PO displays with 2 decimal places.

Go to forum: Wish List

55 Reply by paul

(10 replies, posted in Wish List)

But the side effect is better than before. Adding a new PO or editing an existing PO will not come out right price when using the base current_user.inc.

Go to forum: Wish List

56 Reply by paul

(10 replies, posted in Wish List)

There is a side effect with this. On the printed Purchase Order, the line-item Price column is shown with 14 decimal places. A cost of $18.40 will print here as 18.40000000010000. I will look into the report to see if I can figure something out. Ha! Well, I will try.

I would still prefer to enter a PO in supplier units qty units and cost).

Go to forum: Wish List

57 Reply by paul

(10 replies, posted in Wish List)

Sweet-Pete! That took care of my pricing issue. Way, way beyond my level of comprehension.

  Thanks again Braath!

Go to forum: Wish List

58 Topic by paul

(10 replies, posted in Wish List)

One unit from our supplier is  5760 stocking units to us. It looks like matching  purchase order pricing is going to be tough when entering  an item in our units/price unless I change price decimal places to 8. If an item was entered in the purchase order in supplier units, item costs can vary by calculating back to item units.

Go to forum: Wish List

59 Reply by paul

(25 replies, posted in Accounts Receivable)

OK - all my testing it with tax exempt sales (most of ours). With 2 decimal places, the document sales order fields look correct and goes though ok as best that I can tell. I see what you are saying when I switch to a cash/taxed customer.

Go to forum: Accounts Receivable

60 Reply by paul

(25 replies, posted in Accounts Receivable)

I think the discrepancy only happens on Prepaid Sales Orders when Display Setup's Decimal Places for Prices/Amounts is set to 10. Have you tried a prepaid sales order when decimal places is set to 2?

  Other than the error about the Prepayment Required amount issue on the Sales order, I see predictable/accurate results throughout the process through invoicing in GL when I have decimal places set to 2.

  When I have decimal places set to 10, I also see the strange errors you mentioned especially with the tax amount on a tax exempt sales plus the extra amount. Even an existing, reprinted invoice can show different totals depending on the setting of decimal places.

  I think I have to use Prepaid Sales Orders as Direct Sales Invoice doesn't allow me to wait to ship (and then invoice) an order as some of our orders are custom or made-to-order types that take a few days. I like to record the date of purchase and the date to shipping as we invoice after shipping (even if prepaid).

Go to forum: Accounts Receivable

61 Reply by paul

(25 replies, posted in Accounts Receivable)

Thank you for the tips. I think with prepay, rep107 has a block showing what has been paid, but I am unsure if it indicates amount due. That would be nice to reassure the customer that nothing is due if they paid 100%. Thanks. And I didn't know custom report for a single company could be placed in their own reporting directory. Excellent!

Go to forum: Accounts Receivable

62 Reply by paul

(25 replies, posted in Accounts Receivable)

Well, great! Thanks for the explanation there, Oakstreet. Now that you mention it, I should have picked up on the prepayment required (before delivery)(Banging Head Against Wall). Since we're only recording sales that have already happened (and been paid 100%), I only have to reduce any future problems like this in order to go on.

  Thank you

Go to forum: Accounts Receivable

63 Reply by paul

(25 replies, posted in Accounts Receivable)

I have now tried this on FA 2.4.6 and the three PHP versions and see all the same issues. If I reduce decimal places to only 9 in Display Setup, all looks OK from what I can tell. Even trial balance is balanced, etc.

  I tried a sale without prepaid terms, but believe the same problems were displayed.

  Maybe the work-around is to limit users up to 9 decimal places in Display Setup if problem is external to FrontAccounting?

  It still would not solve my original issue, but I tried another sale and as long as I reduce the Pre-Payment Required field by .01 or more, but not down to 0.00, all seems well in GL from what I can see from sales order to payment, delivery and invoicing. So I still have the question as to the significance of Pre-Payment Required field. Am I missing something important when I reduce this amount in order to save the sales order?

Go to forum: Accounts Receivable

64 Reply by paul

(25 replies, posted in Accounts Receivable)

Thanks Oakstreet. I am finding out about the floating point errors.

  Yes, I am running FA 2.4.7 along with PHP 7.2 and have now also tried PHP 7.0 and 5.6. These attempts did not help my situation.

Go to forum: Accounts Receivable

65 Reply by paul

(25 replies, posted in Accounts Receivable)

Sorry - I believe I don't understand your last comment.

  Also, with 10 decimal places showing, Trial Balance is not balanced. I don't need this kind of precision. I am only looking for a way around the initial issue when saving a new sales order. If the Pre-Payment Required field on the New Sales Order is not used internally for financial accuracy in some way, I think I can just reduce it in order to be able to save the new Sales Order and go on.

Go to forum: Accounts Receivable

66 Reply by paul

(25 replies, posted in Accounts Receivable)

Thanks for the reply Apmuthu.

PHP Version = 7.2.19

precision was at 14 and changed to 17. Restarted and verified precision is 17 under core data from Apache/PHP. No different results in FA. Increased precision even more, restarted Apache and still no changes in FrontAccounting.

Go to forum: Accounts Receivable

67 Reply by paul

(25 replies, posted in Accounts Receivable)

I find this:

  If I increase Prices/Amounts decimal places to 10 in Display Setup, I can go to my items and see that my price has an added 1 at the 10th digit. I entered a price of $22.99 for an item, but FA is showing me $22.9900000001.

  When I start a new Sales Order (with a tax exempt customer) and add one item at 22.99, the Price Before Tax column indicates a price of 22.9900000003 and total for that line is 22.9900000003. Shipping charge already shows 0.0000000001 before I enter the 8.60 (which stays at 8.6000000000), Subtotal shows 31.5900000003. Tax line added shows 0.0000000002 (tax exempt customer, though) which cannot be removed and the Amount Total is 31.5900000007 (not even the 31.5900000005 total it *should* be, but there is an added row with a 0.0000000002 under the Item Code column.. ? that does make the 31.5900000007.

  If I edit the item line and change the price from 22.9900000003 to 22.99 and Confirm Changes, the items price shows 22.9900000001. If I then edit the line again, but simply Confirm Changes without changing anything, the price increases by 0.000000001 each time.

  The Pre-Payment Required field shows 31.5900000005 (which is less than the 31.5900000007, so I'm not sure why FA is complaining).

  I assume the added amounts are a bug, but maybe I have done something wrong and wonder if someone else can confirm these details.

Go to forum: Accounts Receivable

68 Reply by paul

(25 replies, posted in Accounts Receivable)

What is the purpose for the Pre-Payment Required field on the New Sales Order, Order Delivery Details section?

In my above example, $22.99 + $8.60 shipping, the total of $31.59. If I reduce this to $31.58 in the Pre-Payment Required field, I can save the sales order. If I then go into Invoice Prepaid Orders, I see the total of $31.59 left to be invoiced.

Go to forum: Accounts Receivable

69 Reply by paul

(25 replies, posted in Accounts Receivable)

Hi Rafat,

  Thanks for your reply. When I look in Items -> Items Tax Types, I only have one option setup on this test system. When I look at that type in Setup ->Item Tax Types and change the one entry to be fully tax exempt and then not, I do not see a difference when trying to re-enter the sales order.

Go to forum: Accounts Receivable

70 Topic by paul

(25 replies, posted in Accounts Receivable)

Using FA 2.4.7, I am trying to enter a prepaid sales order, but am getting an error:

Pre-payment required have to be positive and less than total amount.
includes/ui/ui_msgs.inc:14:     trigger_error('Pre-payment required have to be positive and less than total amount.','256')
sales/sales_order_entry.php:395:     display_error('Pre-payment required have to be positive and less than total amount.')
sales/sales_order_entry.php:470:     can_process()

  I enter a single item for 22.99 and also a 8.60 shipping charge. This is a no-tax sale. Amount Total field matches Pre-Payment Required fields. If it matters, I have Prices/Amounts Decimal Places set at 2. I believe this is a rounding issue. If I edit the item's price by one penny in either direction and the Amount Total and Pre-Payment fields match the edited amounts, I do not get this error. If I return the item to $22.99 and lower the Pre-Payment field by one penny or more, I do not get this error.

  What am I doing wrong? As before, thank you.

Edit: Additional data entered.

Go to forum: Accounts Receivable

71 Reply by paul

(2 replies, posted in Wish List)

Thanks again Braath. I will look into this.

Go to forum: Wish List

72 Topic by paul

(2 replies, posted in Wish List)

I see the default bank account setting which seems to be company-wide. Would it be helpful to others to add the ability to also set a default bank account to a customer and even possibly a supplier?

Our suppliers are almost always paid from checking account - but not all. Sometimes via credit card. Most of our general customer accounts can prepay into certain accounts depending on the sales channel they purchased from.

  If a default bank account is not set in customer/supplier account, FA looks for company-wide default bank account next.

  Thank you.

Go to forum: Wish List

73 Reply by paul

(4 replies, posted in Setup)

Thank you apmuthu. If I understand you correctly, it seems that using a unique prefix for a company can be safer for data integrity, generally speaking.

Thank you

Go to forum: Setup

74 Topic by paul

(4 replies, posted in Setup)

Is there any benefit to using a database prefix when we are not presently limited to one (or very few) mysql databases on our system?

  One example I thought of: I didn't know if there could be easier store interactions from one company to a second company if they both share the same database with each having unique table prefixes as opposed to two separate databases - One owner, two semi-separate location situation: Locations can transfer material, but financials need to be kept separate.

  Also - With our initial company setup being tested in FA, this company database now has a prefix. If I wanted to use this data and not have a prefix, can the production setup be as easy as creating a new company in FA while specifying no prefix and a new database, use phpmyadmin to drop all of these tables, restore the test database (with prefix) to this new company and use phpmyadmin to replace the prefix with no prefix. Could this method break FA since the initial database had a prefix?

  Thank you,

Go to forum: Setup

75 Reply by paul

(7 replies, posted in Items and Inventory)

Great - Thank you all!

  So, what is the best way to stay "current" to include all that has been and to be committed? It would seem difficult to answer the many questions (from me!) without knowing what version the person is using.

Go to forum: Items and Inventory