Prepaid Sales Order Error: Pre-payment required have to be positive... (Page 1 of 2)

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.

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.

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.

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.

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.

In my quick test setup, sales tax was added, which actually made the prepayment amount incorrect. The amount displayed was the full price of the invoice (including tax) plus the tax (a second time). So the tax was $0.60 and the prepaid amount was $0.60 more than the invoice total.

It did let me enter the sales order with the manually corrected prepaid amount. I've never done this before, so I am not sure what to expect. It appears I must now enter payment from the customer before I can make a delivery and invoice the customer ...

However, the sales order amount shows incorrectly, in the same way the prepaid amount was incorrectly computed. I entered the correct amount, rather than paying the full allocation and then I was able to make a delivery on the sales order which had the correct total, so I assumed the invoice would get the correct amount.
However, when I went to generate an invoice on the prepaid, and now delivered sales order, the invoice doesn't include the shipping charge so the invoice amount is wrong.

As I mentioned, I've never used prepaid sales orders, so I'm not totally clear on how this should work, but it looks to me like there are some serious discrepancies.

I will post database entries next for review ...

The 0.16 discrepancy in the S&H amount (GL = 8.44, DEL=8.60) accounts for the difference in tax amount.
So, if it's possible to figure out how the S&H got reduced to $8.44, the tax amounts should be consistent.

One more note: I just did an identical sales order without using prepaid terms and the GL amounts and tax entries are correct.

The only purpose of pre-payment required is to enforce a certain amount of payment, up to the order total, before delivery is enabled.
So, if you have one person or group of people entering sales orders, and someone else handling deliveries, the people handling deliveries will not be able to make a delivery until a payment is entered against the SO that is at least equal to the prepayment amount.
So, the pre-payment amount cannot exceed the order total, but may be less.

In that case you probably want to just enter a direct invoice. That will create a sales order, mark all items as delivered, and generate the invoice for billing.

If you find rep107.php under reports, you can add some lines like the following (search for $DisplayTotal) to find where to add these lines. Note that I created an invoice total variable and edited the display total line to use it. Otherwise, I just added 6 new lines ...
(if you want a custom invoice form, it's best to make a copy of the original file in company/X/reporting where "X" is the company number. FA should use the custom form in the company/X/reporting folder in place of the original one in reporting/)

            $rep->NewLine();
        $invTotal = $myrow["ov_freight"] + $myrow["ov_gst"] + $myrow["ov_amount"]+$myrow["ov_freight_tax"];
        $DisplayTotal = number_format2($sign*$invTotal,$dec);
        $rep->Font('bold');
        if (!$myrow['prepaid']) $rep->Font('bold');
        $rep->TextCol(3, 6, $rep->formData['prepaid'] ? _("TOTAL ORDER VAT INCL.") : _("TOTAL INVOICE"), - 2);
        $rep->TextCol(6, 7, $DisplayTotal, -2);

        $rep->NewLine();
        $rep->TextCol(3, 6, "AMOUNT PAID", - 2);
        $rep->TextCol(6, 7, number_format2($myrow['alloc'],$dec), -2);

        $rep->NewLine();
        $rep->TextCol(3, 6, "AMOUNT DUE", - 2);
        $rep->TextCol(6, 7, number_format2($invTotal - $myrow['alloc'],$dec), -2);

Also, you only get that block on your invoice if you use the prepaid invoice feature, which is causing some strange errors. When I did it, it applied sales tax on shipping for a tax exempt customer, but applied it inconsistently, discounted the shipping by $0.16 (about 2%), and calculated the sales tax amount on the incorrect shipping in 2 places where it was calculated on the full shipping price in other places.

Finally, the prepaid invoice I generated showed the wrong sales tax amount, but the correct total, so if you add up the numbers, the computed total doesn't agree with the invoice total.

Until the prepaid order is fixed, I wouldn't use it. I'd be afraid my GL reports were going to get totally screwed up.