It's much more fun, when you can discuss your problems with others...
You are not logged in. Please login or register.
FrontAccounting forum → Posts by apmuthu
The missing 2nd argument for the $Refs->is_valid() method has been fixed using a session value - if this does not work, then the transaction type ($type) must be passed on as an argument to the can_process() function.
There is also a fix needed to the core for tax groups function. Line 128 of taxes/db/tax_groups_db.inc:
function get_shipping_tax_as_array($id)should be:
function get_shipping_tax_as_array($id=null)@joe: can fix the core.
Currently there is no direct integration of FA with any external POS within FA. You will need third party integration code or import / export transactions between the two. FA has import/export items and import transactions as official extensions.
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.
@notrinos: Why does it work everywhere else? What happens if the "exit;" is commented out in the main function itself?
@joe: was that some debug code that got left behind or do we need another argument for the function to conditionally execute an exit?
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.
The extension file must overwrite the one in the modules/rep_customer_ledger folder.
The files in the core will have to be replaced from the "altered" folder in the file attached in my previous post.
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!
This requires changes to the core FA attached.
The modified report extension is available from here.
@joe: please commit the attachment for making the Areas Filter on reports have an "No Areas Filter" option in the dropdown box.
@joe: Thanks for the commit.
Which report are you referring to?
They are not redundant entries. They only appear so because they are named so. The customer is a different entity and the payment receipts go into a bankable account.
Following every unique assist request will help avoid requests in future on similar lines and fill the self service knowledgebase. It may also throw up errors or suggest improvements that will benefit the community at large when settled.
Do not choose to select any Sales Area - then all Sales Areas will be selected - that is for no filter on Sales Areas.
Provide screenshot of what you did while entering the JE.
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?
Whilst the Purchase Order Tax is temporary, the Tax on the Purchase Invoice is permanent. The Inventory Purchase Report - rep306.php can be extended to show the tax on each item. The effective sql used there is:
SELECT item.category_id
, category.description AS cat_description
, item.stock_id
, item.description
, item.inactive
, move.loc_code
, supplier.supplier_id
, supplier.supp_name AS supplier_name
, move.tran_date
, move.qty AS qty
, move.price
FROM 1_stock_moves move
LEFT JOIN 0_supp_trans credit ON credit.trans_no=move.trans_no AND credit.type=move.type
LEFT JOIN 0_grn_batch grn ON grn.id=move.trans_no AND 25=move.type
LEFT JOIN 0_suppliers supplier ON IFNULL(grn.supplier_id, credit.supplier_id)=supplier.supplier_id
INNER JOIN 0_stock_master item ON item.stock_id=move.stock_id
INNER JOIN 0_stock_category category ON item.category_id=category.category_id
WHERE (move.type=25 OR move.type=21)
AND (item.mb_flag='B' OR item.mb_flag='M');
-- ST_SUPPRECEIVE = 25
-- ST_SUPPCREDIT = 21The 0_supp_trans.ov_gst is expected to contain the tax.
Tax is available for invoicing. I meant about Tax being listed in a report.
Check if the exchange rate urls are manually accessible.
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.
The concept here is that the GL Account for Cash is different from the Customer Cash Account where all cash customers get billed. Since it is immediate cash, the tracking of Accounts Receivable is not necessary but needed for turnover / transaction listing.
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?
Actually, the Sales Invoices import was coded later and old PHP's graceful degradation based on loose type acceptance is no longer available.
Try this version now.
The ERD is now on the Wiki.
FrontAccounting forum → Posts by apmuthu
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.