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
Use FireFox on one window for one company and possibly Chrome or other compatible browser for the other company in another window.
Cookie and session names can be customisable and making a unique browser instance recognisable is also possible using appropriate headers but what of separate tabs / windows using the same company's instance - like opening a link in FA in a new window? How do we then differentiate the two scenarios?
Where would you store the "total agreed contract value" in FA at the time of making the Purchase/Sales Order? Probably as free form text in the Memo field?
At the time of invoice preparation, the reporting/rep107.php (Invoice Script) can be customised to change / eliminate wordings / fields but to get data that was not stored is well nigh impossible!
This can be programmed as a trigger in the mysql database itself irrespective of what FA computes and enters in the DB. Beware of amendments and deletions.
Nice slab feature for FA 2.5.
Try the attachment and fix the encoding in the installed_extensions.php file in both the FA webroot and in the Company/# folders as well in case you had installed the iso version earlier.
The memo field can contain the additional references.
The above requires change of db schema.
Just put in the phone number as part of the memo / description for the invoice and search there from.
This is because of google analytics being used which is not compliant with the samesite attribute.
Ref:
https://www.tinstar.co.uk/studio-blog/some-cookies-are-misusing-the-recommended-samesite-attribute-how-to-fix/
https://support.google.com/tagmanager/thread/28637813?hl=en
This is a nice feature request for reporting/rep710.php.
Attached is the diff and modded file.
@joe: can add it into the core with improvements.
Beware of adding apples and oranges. The Action column can be "Changed" or "Closed" for which there is no filter in the form request.
The 10th parameter comes from get_unit_cost($line->stock_id)
Update the extension from the FA24extensions repo.
This error line is at line 255 in includes/session.inc.. It is likely that your PHP version may be to blame (even some minor version number change has it's anomalies). Looks like no user logged in may be a blank or null interpreted by the if check wrongly in the specific version. Also check permission of files and folders and writeable tmp folder.
It is possible that the Arabic abbreviation works in the FA UI but will need to be in English (IMHO) as it is a parameter to the appropriate function through the SlimAPI (probably the way it is implemented as there is no language/theme info in the API) and not a direct variable from a translatable form.
This is entered via "Quick Entries" since the actual expense account to be allocated to is different for different expenses.
However, you can also make a set of entries you wish to enter through the Import of Journal entries extension too.
In your instance, the amounts were different across vouchers and appear multiple times, but such occurrence is due to the voucher number being same. There should be no linkage with amount as we can have the same amount legitimately in the same day for the same account too. Check on duplication in the reference: BKPMT-00010. Maybe if the taxes are different you might want to have different account numbers for each.
State which version / date of FA you are using. Please note that the file referred to was last changed on 2015-12-12 and no one has complained about it in the last few years.
Currency abbreviation must be in English only.
Possibly the report re-calculates it instead of taking the adjusted value. Make the adjustment with some dummy "receipt of inventory" and see what happens.
Then just like @flpages says, close GL transactions each day. If Admin wants to allow it, then close later. This is the best way for now.
@rahmanbd: please do not post same issue in several topics.
Backdate entry sys_prefs variable can work in unexpected ways like when time zone is taken into account. Editing any field in an invoice is fraught with foreign key issues. Best is not to allow any edition at all and allow deletion and make fresh entry or make credit/debit note entries and supplementary invoices for any differences envisaged. Accounting is serious business - no marks for a good try.
Use the memo / description field instead and make sure the initial prefix to the chq number like CHQ4564334 is used and then parse out all memo entries that start with CHQ and has the first word as say 10 characters long separated by a space of terminated therewith.
@joe: any sys_prefs flag to prevent selling below cost?
Monies as journal entries are unallocatable. It can be allocatable only if passed on as credit/debit notes. Hence we keep the reference optional.
Check number can be done through it's own table in an extension or used passively in the memo field.
In FA 2.5 it might be a good feature to include and useful for reconciliation too. Formatted memo fields can be a good way to get the check number parsed out to link to some other table possibly through a trigger (editions beware).
Again, this is a "feature" to provide for freebies and encash obsolete stocks as well. Buy a cat for a million and get the house free!
This can be done only in the FA v2.5.
@joe: see where to place this min price / expression of a field.
The way FA is currently setup is that the salesman is part of the cust_branch table and that dictates the inquiry and reports as well.
As FA v2.4.x has frozen the DB schema, we can make this new feature in FA 2.5 only or in the meanwhile, make an extension for it.
Alternatively, we can possibly keep the salesman in the cust_branch table as the default and keep a flag in the sys_prefs table for overriding it using the logged in user but what if the logged in user does not happen to be a salesman at all? Hence this filter too has to be applied before using the override - that the logged in user is a salesman indeed.
@joe: looks like in this way we can address this issue and modify the views/inquiries and reports to accommodate it as well.
The logic is that whoever keys in the transaction may not always be the real salesman.
Also, FA recognises the sales person as the one listed in the #_cust_branch table.
This is more of an account manager to whom a subset of customers are assigned.
If you want to change the salesperson, then see that the change is made in the said table.
FrontAccounting forum → Posts by apmuthu
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.