FrontAccounting forum — Prepaid Sales Order Error: Pre-payment required have to be positive...

Re: Prepaid Sales Order Error: Pre-payment required have to be positive...

null@example.com (paul) — Fri, 30 Aug 2019 18:32:04 +0000

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.

Re: Prepaid Sales Order Error: Pre-payment required have to be positive...

null@example.com (oakstreet1) — Fri, 30 Aug 2019 18:23:43 +0000

All of my testing has been with decimals set to 2, but the error only happens if you add sales tax on freight (AFAIK). However, if you do that, you are guaranteed to get some invalid numbers.

I reported a bug. It may be something fairly easy to fix, since it is pretty predictable.

Just be sure your Accounts Receivable balance is correct. That is probably where the errors are the most noticeable ... that and when an invoice shows an incorrect total.

Re: Prepaid Sales Order Error: Pre-payment required have to be positive...

null@example.com (paul) — Fri, 30 Aug 2019 18:19:19 +0000

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).

Re: Prepaid Sales Order Error: Pre-payment required have to be positive...

null@example.com (oakstreet1) — Fri, 30 Aug 2019 16:50:22 +0000

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.

Re: Prepaid Sales Order Error: Pre-payment required have to be positive...

null@example.com (paul) — Fri, 30 Aug 2019 16:04:34 +0000

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!

Re: Prepaid Sales Order Error: Pre-payment required have to be positive...

null@example.com (oakstreet1) — Fri, 30 Aug 2019 14:52:22 +0000

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);

Re: Prepaid Sales Order Error: Pre-payment required have to be positive...

null@example.com (paul) — Fri, 30 Aug 2019 14:42:01 +0000

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

Re: Prepaid Sales Order Error: Pre-payment required have to be positive...

null@example.com (oakstreet1) — Fri, 30 Aug 2019 14:29:34 +0000

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.

Re: Prepaid Sales Order Error: Pre-payment required have to be positive...

null@example.com (paul) — Fri, 30 Aug 2019 14:23:30 +0000

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?

Re: Prepaid Sales Order Error: Pre-payment required have to be positive...

null@example.com (oakstreet1) — Thu, 29 Aug 2019 23:43:33 +0000

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

Re: Prepaid Sales Order Error: Pre-payment required have to be positive...

null@example.com (oakstreet1) — Thu, 29 Aug 2019 23:38:43 +0000

I just noticed that the deferred income amounts appear to be wrong, also.

The only strange thing I did in producing these results was to adjust the prepaid amount on the sales order entry to match the correct order total from the incorrect amount that was displayed.

Re: Prepaid Sales Order Error: Pre-payment required have to be positive...

null@example.com (oakstreet1) — Thu, 29 Aug 2019 23:36:37 +0000

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.

Re: Prepaid Sales Order Error: Pre-payment required have to be positive...

null@example.com (oakstreet1) — Thu, 29 Aug 2019 23:34:08 +0000

This is the data review of my test. There are some serious red flags. The total amount in the sales order is wrong and at least 2 of the GL entries are wrong. Also, one entry in the tax table is rounded and another is not.

sales order record for order_no=34

| ord_date   | order_type | freight_cost | delivery_date | payment_terms | total | prep_amount | alloc |
+------------+------------+----------+---------------------------------+---------------+---------------+
| 2019-08-29 |          1 |          8.6 | 2019-09-28    |             5 | 32.79 |       32.19 | 32.19 |

Note: The sales order total is 0.6 greater than the total of item, shipping and freight tax.

sales order details records for order_no=34

| id  | order_no | trans_type | stk_code | description       | qty_sent | unit_price | quantity | invoiced | discount_percent |
+-----+----------+------------+----------+-------------------+----------+------------+----------+----------+------------------+
| 117 |       34 |         30 | 103      | iPhone Cover Case |        1 |      22.99 |        1 |        0 |                0 |

debtor trans records for order_ = 34

Delivery Transaction:
| trans_no | type | tran_date  | due_date   | reference | tpe | order_ | ov_amount | ov_gst 
+----------+------+------------+------------+-----------+-----+--------+-----------+-------
|       33 |   13 | 2019-08-29 | 2019-09-28 | 001/2019  |   1 |     34 |     22.99 |      0 

| ov_freight | ov_freight_tax | ov_discount | alloc | prep_amount | rate | ship_via | payment_terms | tax_included |
+------------+----------------+-------------+-------+-------------+------+----------+---------------+--------------+
|        8.6 |            0.6 |           0 |     0 |       32.19 |    1 |        1 |             5 |            0 |

Invoice Transaction:
| trans_no | type | tran_date  | due_date   | reference | tpe | order_ | ov_amount | ov_gst 
+----------+------+------------+------------+-----------+-----+--------+-----------+-------
|       33 |   10 | 2019-08-29 | 2019-08-29 | 02595     |   1 |     34 |     22.99 |      0

| ov_freight | ov_freight_tax | ov_discount | alloc | prep_amount | rate | ship_via | payment_terms | tax_included |
+------------+----------------+-------------+-------+-------------+------+----------+---------------+--------------+
         8.6 |            0.6 |           0 | 32.19 |       32.19 |    1 |        1 |             5 |            0 |

Note: The delivery and invoice transaction details have the correct amounts.

id |debtor_trans_no|debtor_trans_type|stock_id|description      |unit_price|unit_tax|quantity|discount_percent|standard_cost|qty_done|src_id
---+---------------+-----------------+--------+-----------------+----------+--------+--------+----------------+-------------+--------+------
202|            33 |              13 | 103    |iPhone Cover Case|    22.99 |      0 |      1 |              0 |          10 |      0 |   117

Customer allocations:

| id | person_id | amt   | date_alloc | trans_no_from | trans_type_from | trans_no_to | trans_type_to |
+----+-----------+-------+------------+---------------+-----------------+-------------+---------------+
| 31 |         9 | 32.19 | 2019-08-29 |            15 |              12 |          33 |            10 |


Trans Tax Details (this may be the floating point error):

| id | trans_type | trans_no | tran_date  | tax_type_id | rate | ex_rate | net_amount | amount           | memo     | reg_type |
+----+------------+----------+------------+-------------+------+---------+------------+------------------+----------+----------+
| 70 |         10 |       33 | 2019-08-29 |           1 |    7 |       1 |        8.6 | 0.58902104300091 | 02595    |        0 |
| 71 |         10 |       33 | 2019-08-29 |           0 |    0 |       1 |      22.99 |                0 | 02595    |        0 |
| 68 |         13 |       33 | 2019-08-29 |           1 |    7 |       1 |        8.6 |              0.6 | 001/2019 |     NULL |
| 69 |         13 |       33 | 2019-08-29 |           0 |    0 |       1 |      22.99 |                0 | 001/2019 |     NULL |


General ledger entries:
| counter | type | type_no | tran_date  | account | memo_ | amount   | person_type_id | person_id |
+---------+------+---------+------------+---------+-------+----------+----------------+-----------+
|     199 |   12 |      15 | 2019-08-29 | 1060(CHECKING)  |    32.19 |           NULL | NULL      |
|     200 |   12 |      15 | 2019-08-29 | 1200(AR)|       |   -32.19 |              2 | 9         |
|     201 |   13 |      33 | 2019-08-29 | 4020(TAXABLE SALES) -22.99 |           NULL | NULL      |
|     202 |   13 |      33 | 2019-08-29 | 5010(COGS)      |       10 |           NULL | NULL      |
|     203 |   13 |      33 | 2019-08-29 | 1510(INVENTORY) |      -10 |           NULL | NULL      |
|     204 |   13 |      33 | 2019-08-29 | 2390(DEFER INCOME)   22.99 |           NULL | NULL      |
|     205 |   10 |      33 | 2019-08-29 | 2390(DEFER INCOME)  -22.57 |           NULL | NULL      |
|     206 |   10 |      33 | 2019-08-29 | 1200(AR)|       |     31.6 |              2 | 9         |
|     207 |   10 |      33 | 2019-08-29 | 4430(S&H)       |    -8.44 |           NULL | NULL      |
|     208 |   10 |      33 | 2019-08-29 | 2150(TAX)       |    -0.59 |           NULL | NULL      |

Note that the tax entry is off by 1 penny from the invoice and I don't know where the S&H amount of $8.44 came from.

If you copy my data into a wider display, it will look better. I tried to remove unneeded fields to prevent the display from wrapping in a confusing way.

Re: Prepaid Sales Order Error: Pre-payment required have to be positive...

null@example.com (oakstreet1) — Thu, 29 Aug 2019 22:48:23 +0000

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 ...

Re: Prepaid Sales Order Error: Pre-payment required have to be positive...

null@example.com (oakstreet1) — Thu, 29 Aug 2019 21:51:32 +0000

paul wrote:

... have now also tried PHP 7.0 and 5.6. These attempts did not help my situation.

That's actually good, because it will be quicker for me to install 2.4.7 on PHP 5.6 for testing.