Skip to forum content
FrontAccounting forum
It's much more fun, when you can discuss your problems with others...
You are not logged in. Please login or register.
Active topics Unanswered topics
Search options (Page 89 of 247)
Topics by apmuthu User defined search
Posts found: 2,201 to 2,225 of 6,163
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?
Those developing the core FA code and / or extensions are advised to follow some of the common constructs espoused in PSR-1 other than namespace advisories for now.
For those using const and define, the differences are listed here.
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 = 21
The 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.
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.
When we first login to FA, there is no $_SESSION[$cartname] available.
When we then choose Sales => Direct Sales Invoice and then we change the payment terms first we get the error:
This edit session has been abandoned by opening sales document in another browser tab. You cannot edit more than one sales document at once.
The fix is to change line 49 in sales/includes/sales_ui.inc:
if ((!isset($SysPrefs->no_check_edit_conflicts) || $SysPrefs->no_check_edit_conflicts==0) && $cart_id && $cart_id != $_SESSION[$cartname]->cart_id) {
to
if ((!isset($SysPrefs->no_check_edit_conflicts) || $SysPrefs->no_check_edit_conflicts==0) && $cart_id && isset($_SESSION[$cartname]) && $cart_id != $_SESSION[$cartname]->cart_id) {
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?
Setup => payment Terms => create new payment terms as Cash type but name it credit card. make an account code similar to cash and call it credit card. Make it a bank account - your merchant bank account.
It appears that the first non default cash type of account in the bank accounts gets hard coded in creating a direct invoice.
Quick Entries as in this post may be useful.
@joe: What is the correct way to make a "Cash" sale (Payment Terms) for a credit card transaction.
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.
Tax is set to be included in your price so 5000 * 0.05 / 1.05 = 238.10 SR. Setting it to be Tax Excluded will result in 250 SR = 5000 * 0.05. This setting is in Sales => Sales Types => Tax Incl (checkbox).
Then it should be a browser and version issue / OS issue.
Posts found: 2,201 to 2,225 of 6,163