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
How (and from where) did you install the said extensions?
All extension files will reside in modules/<extension>/ folder.
The file includes/db/references_db.inc is present in FA v2.3 and not in FA v2.4. You may have just copied over the FA 2.4 files onto an existing FA 2.3 install.
The extensions in the FA 2.4 official repo should work - that is why they are signed and stated to be "official". Try them out and see what breaks and report back for corrections.
The said link is for an FA version and SimpleAPI version that is quite dated but needs to be modified to suit the current versions. It is there as an example to modifiy as required when changes occur. What are you trying to do with the SimpleAPI?
The file includes/packages.inc defines the function check_src_ext_version() and returns tru only if the package version >= application version. Here the latter is the FA version defined in line 9 of version.php as $src_version = "2.4.RC1"; and the former is the Payroll Module version. As your module is not packaged, there is no version number displayed in it's entry in installed_extensions.php file both in the webroot and in the company/#/ folder where you can manually make an entry for the version.
@joe: If no version is present like this for manually installed custom modules, the line 215 in admin/inst_modules.php:
if (check_value('Active'.$i) && !check_src_ext_version($ext['version']))can be modified to check the latter condition only if the $ext['version'] is not empty.
Tweak the permissions of the roles and report what is absent / needed.
Hardcoding specific users presence in the session variables is one workaround if it is not available as a user. Please note that some transactions may not have any "user ownership" and the audit trail may be the only way to glean it from.
Whilst the extensions for FA 2.4RC1 are okay to be taken from the official repo where they are expected to get updates, the FA 2.3.x extensions may need corrections that are listed in my unofficial repo.
As for your Web Root, where did you set it From the debug notice, it appears that your webroot is still set at the default of C:\Inetpub\wwwroot with /FA as the subfolder. Try to move your c:\wwwroot\FA\* to C:\Inetpub\wwwroot\FA\ and see if all is well.
The project would certainly do well with donations from satisfied users like yourself. Thanks. The devs would certainly find it encouraging.
Choose to update the administrator and other users with appropriate permissions in the user roles for the new modules in the target company after logging in there.
Quotations / Orders do not enter the ledger.
1. You can choose to have 2 separate companies in FA -> one the actual one, and the other a staging one where entries for approval are made. You can then export out those entries from the staging one on approval and import them into the actual one.
2. You can take a backup first. Let the staff make the entries for approval. Export out those entries that have been approved. Restore from backup. Import the approved entries. Take a backup again and go on all over again....
Going forward, in FA 2.4.x, we can have a separate data entry operator permission with inactive flag set on each transaction entered. The actual accountant with the approval rights gets to remove the inactive flag on approval whensce it gets into the ledger.
SynPOS locations
Refer line 44 in sales/create_recurrent_invoices.php:
$doc->Comments .= sprintf(_("Recurrent Invoice covers period %s - %s."), $from, add_days($to, -1));and change as needed.
Yes on both counts.
Assign it as a "Bank" Account.
https://frontaccounting.com/fawiki/index.php?n=Help.BankAccounts
If you are working with html emails, can they not be preferentially attached with some includes / css to achieve what you want? "Some" of the emails need some place to to store / flag them for such decisions or based on some logic even if just pertinent to you.
Emails are handled by the class in reporting/includes/class.mail.inc. See if you want to include some conditional header in them.
Delivery does not have amounts. rep101.php pertains to customer amount balances.
First off, the Amount field is present in the standard Audit Trail Report 710.
Your PDF of the lacunae in the Audit Trail is appended to this post for forum asset self sufficiency.
The database schema for FA 2.3.x has been frozen. Any changes to it will need to be done in FA 2.4.x only.
The amount field comes from the gl_trans table. Hence it is the GL Transactions table record insertion / updation that needs to be attended to and not the reporting script per se.
https://github.com/rossaddison/import_transactions
https://github.com/serbanconstantinescu/bank_import
Does this bug appear in the other implementation?
Post a copy of the SQL statements after they are formed in the report file.
An MT940 is a standard structured SWIFT Customer Statement message. In short, it is an electronic bank account statement which has been developed by SWIFT. It is a end of day statement file which details all entries booked to an account.
Each bank may implement it as a subset of the standard SWIFT format omitting / understanding optionals differently.
Deutsche Bank MT940/942 format specifications
Compare the tags and separators and check with all possibilities of your specific bank's format and see what you can compare with those used in the FA extension.
Submit a sample MT940 file with confidential info replaced with dummy ones and see if the developers of the import extension can include it.
See if you can download it manually. It may be a route to host issue. Clear dns cache.
PHP 5.3 is recommended.
PHP 5.4/5.5 have met with success...
MySQL 5.0, 5.1, etc are okay but v5.6 should have strict date setting off.
Apache 2.2/2.4 are okay.
Advance payment to supplier should be a "loan" till the invoice is booked.
Debit Card, direct debit, standing order etc are "cheques" in FA where the Transaction number can be the Cheque Number. Make it part of the name of the Bank Account.
Once the Profit/Loss has been calculated, it comes in as a single entry of Balance Sheet class that should match the rest of those there, with the difference matching cash on hand (debit).
The person_id field is either an int or a tinyblob field in FA's tables (Charts of Accounts).
The tables bank_trans, budget_trans, gl_trans have it as a tinyblob (the only ones to have tinyblob fields in FA) field type whilst the tables crm_contacts, stock_moves have it as an int type. In some instances like customers (debtors), branches, suppliers, etc., the respective id portion of the primary key references the person_id field of int type.
The tinyblob field stores the textual string as a hex number. Removing the leading 0x from it, is the hex_number which can be converted using UNHEX(hex_number) function in MySQL to it's original string value.
In includes/types.inc, the function payment_person_name() (and other payment functions therein) routes the person_id field according to the incoming context type it refers to. The usage of the tinyblob field is visible in line 213 of gl/includes/db/gl_db_banking.inc in the function add_bank_transfer():
$person_id = _("From")." ".$fromact['bank_account_name']." "._("To")." ".$toact['bank_account_name'];Also in lines 221 and 224 and others, the functions add_bank_trans() and add_gl_trans() use the variable $person_id assigned above.
Hence the tinyblob field can be changed to varchar or tinytext field without disturbing the code and obtaining clarity in the sql backups. We may need to deal with collations and character sets used in the database if such a change is made.
array_combine() now returns array() instead of FALSE when two empty arrays are provided as parameters.
To ensure compatibility with later versions of PHP whilst retaining backward compatibility, most instances of array_combine(... have been replaced with (object)(array_combine(... except in includes/ui/ui_lists.inc which may be set right now in both branches.
Line 2370 in FA 2.3.25+ and line 2538 in FA 2.4RC1+:
$services = array_combine(array_keys($payment_services), array_keys($payment_services));should now become:
$services = (object)array_combine(array_keys($payment_services), array_keys($payment_services));Fixed in my FA 2.3.x repo.
FrontAccounting forum → Posts by apmuthu
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.