Search options (Page 88 of 246)

The "original" if for the devs to compare. The ".diff" is for the devs to patch the repo. Only the "altered" is for your install.

Yes. Enter a credit and a debit entry atleast. You have entered only a debit to Account 2160. Where do you want to credit it? Possibly credit to some Tax Expenses / Tax Paid Account.

Yes. Only then can you track all such transactions separately.

If someone comes to the shop and buys on cash sale and you prepare a cash invoice and then he says I'll pay you in the evening and if he does or doesn't - it will only be remembered in your mind (or in the memo field) till then!

@joe: Thanks for the commit.

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.