Search options (Page 87 of 245)

Do not choose to select any Sales Area - then all Sales Areas will be selected - that is for no filter on Sales Areas.

Examples of meta_forward() usage are here where the get variables are overwritten.

Which of the 5 lines calling the meta_forward() constructs did you comment out?

Tax is available for invoicing. I meant about Tax being listed in a report.

Only rep209 - Print Purchase Orders - shows Tax on Purchases.
A Print Purchases Listing is needed - both summary and detail.

The function get_po() defined in reporting/rep209.php  uses an sql that has the field tax_included twice with no aliases to differentiate them on fetching them into an array - which one will supercede for it?
The table purchase_orders and the table suppliers both have the field tax_included.

The currently effective sql before filtration and additional columns in get_po() is:

SELECT po.*
     , supplier.supp_name
     , supplier.supp_account_no
--     , supplier.tax_included
     , supplier.gst_no AS tax_id
     , supplier.curr_code
     , supplier.payment_terms
     , loc.location_name
     , supplier.address
     , supplier.contact
     , supplier.tax_group_id
FROM 1_purch_orders po 
     INNER JOIN 1_suppliers supplier ON (po.supplier_id = supplier.supplier_id)
     INNER JOIN 1_locations loc ON (loc.loc_code = po.into_stock_location);

@joe: FA without Purchase Tax reporting is really handicapped.

Any modifications to the code in the current scripts without altering db schema will entail hardcoding for a specific install with account names / types and ids and that will not be generic. Both Cash and Credit Card are of Cash Type as far as the Payment Terms classification is concerned and that is why the simplified entry form gets displayed. If English is the only language to be used, then hardcoding to see if the word "Cash" is present in the name of the description of the Payment Terms can be attempted. The ramifications of the default POS being different from the one in the user's table will have to be studied. There could be several credit card merchant accounts in one installation where this would fail. Appending the account code to the last part of the Payment Terms description is the only way out for now.

@joe: what say you?

The ERD is now on the Wiki.

Line 580 in sales/includes/ui/sales_order_ui.inc:

        label_row(_("Cash account:"), $order->pos['bank_account_name']);

is responsible for the choice of account. It comes from the field sales_pos.pos_account which is looked up on the field bank_accounts.id whose corresponding field bank_accounts.account_code is the account to which the money flows. The field bank_accounts.bank_account_name is what gets displayed.

The POS is fixed in the users table and hence it this that ultimately determines the hardcoded value of the cash account! Hence, create a user and assign the Credit Card POS and link it to the Credit Card Cash Type account and login as that user to perform such transactions.

The issue here is to make the hardcoded Petty Cash Account as a dropdown set of bank accounts for Cash term sales documents. Otherwise, should a default hardcoded account to receive payments into be set in the Payment Terms for Cash Type using an extra field?

This error comes since you are not using the FA 2.4.3+ master. This error has since been fixed in the repo. Last week's commit and the update 3 days ago fixed it.

The zip of changed files from the release are available in this post.

Then it should be a browser and version issue / OS issue.