Search options (Page 9 of 11)

Void of a sales invoice does not void the sales order.    You can reuse the same sales order.  You do not have to type the already inputs again (except for quantities: void of a direct invoice (auto generated delivery) clears the quantities in the sales order but the void of a manual invoice does not).

Thus, to edit a sales invoice:

1.  void the invoice.
2.  If the sales invoice was a manual invoice, void the delivery (void of a direct invoice auto-voids the delivery).
3. edit the sales order and process
4. process the delivery
5. process the invoice

On my site, I have a page that does these steps somewhat automatically, thus creating the appearance of being able to edit any invoice.

In summary, FA does not prevent the edit of an invoice.  It just requires more steps.

Wiki-ed.

My gl_account_inquiry.php differs from the core because it offers the person-type/person-id filters, just like the quickreport extension.  So the call in my gl_account_inqury.php is:

    $result = get_gl_transactions($_POST['TransFromDate'], $_POST['TransToDate'], -1,
        $_POST["account"], $_POST['Dimension'], $_POST['Dimension2'], null,
        input_num('amount_min'), input_num('amount_max'), get_post('person_type'), get_post('person_id'), $_POST['Memo']);

Without the person-type/person-id filter code, those parameters can be null.

In quickreport.php and my gl inquiry, the person-type/person-id list is ajax enabled.   One regret is that the code does not search on the Miscellaneous person type so perhaps there should be an additional <no search> entry in the list.

The original impetus to add the person-type/person-id filter was because there is no other way of searching for quick entry transactions in FA.

@apmuthu: I fixed the reset problem you mentioned.  Thanx.

I have a differing core and the get_gl_transactions() differs in several ways.  One difference is the person_type argument that you mention.   Another difference is that the filter_type parameter accepts a list of gl types instead of just one, which is necessary for the balances to be correct in this report by not displaying deliveries.   A third difference is that the memo field searches by both gl memo and comment memo.

The purpose of this inquiry page is to condense the display of g/l account transactions by placing the two accounts of a double entered transaction into separate columns rather than on separate lines like the standard gl inquiry.   If there are more than two accounts for a transaction, it displays "split".

This is helpful in visually identifying transactions entered into wrong accounts because often transactions use the same accounts each time.   For example, payments to a fuel supplier might usually use the accounts "Auto Expenses" and "Credit Card".   If one scans down the list of transactions for this supplier and then sees "Office Expenses" on one transaction, it probably was incorrectly entered and appropriate action can be taken (by clicking on the pencil to edit the transaction).

The lists need special character handling so that names like "A & L" Foods appear properly.  One possible fix is to call

function decodeHtml(html) {
    var txt = document.createElement("textarea");
    txt.innerHTML = html;
    return txt.value;
}

where the code currently uses "selval" and

selectedoption.innerHTML= selectedoption.innerHTML.replace(/&nbsp;/gi,' ');

which currently may not be doing anything because the browser just converts back.

Another minor problem is lost focus because FA does not expect to focus on a hidden variable, which in the new code has the old list name (the new list being named "name" + mselect).  I have a simple fix for this if you are interested.

Thanks for the contribution.  I already had autocomplete lists running on my site but I like yours better because it modular and non-invasive, so I replaced my code with yours.

This was a recent commit after the original pull request (https://github.com/FrontAccountingERP/FA/pull/32), which was not included in the core.

The earlier commit always used the dimension from the customer branch to dimension customer payments so there was no need to specify dimension on the customer payments page.

The recent commit was needed to handle a special case where a customer was invoiced separately by two separate dimensions of a company but the customer paid both invoices with a single check, so dimension was added to the customer payments screen to split the payment to the proper dimensions.

The purpose of these commits as stated in the original pull request, is to keep A/R correct when tracked separately by dimension.   If one does not need to track A/R separately by dimension, FA works correctly without these commits.

See https://frontaccounting.com/punbb/viewtopic.php?id=7463.  Fix is same for suppliers/items/customers.

I think many would like to see this in freely available code.

Not what you would want, but we are using the ancient web cart "oscommerce" and the FA oscommerce extension to do much of what you ask.

Wild guess: maybe the customer statement report should screen voided transactions like the other customer balance methods mentioned?

In vanilla FA, I believe you can configure the number of items by changing  core/config.default.php:

    $max_rows_in_search = 10;

For next page, you would have to change the code, such as is done in https://github.com/braathwaate/frontac24/commit/5bf114b9fe1974331709e18e7d13c337ba939716.

You can void the invoice, then void the delivery, then edit the sales order, then deliver again, then invoice again.

This is done in the extension,  https://github.com/braathwaate/FA24extensions/blob/master/Extensions/bank_gl_inquiry/bank_gl_inquiry.php.  Look for the call to get_dimension_string().

I didn't know it changed, but to show them,

sales/includes/db/cust_trans_db.inc
function get_sql_for_customer_inquiry

Change line 351 to:

    // exclude voided transactions :
            ." AND ISNULL(v.date_)"
        // exclude self-balancing (journal) transactions:

      ." AND (trans.type = " . ST_SALESINVOICE . "
            OR (trans.ov_amount + trans.ov_gst + trans.ov_freight + trans.ov_freight_tax + trans.ov_discount) != 0)";