Search options (Page 171 of 246)

Developments to the Unstable branch FA v2.4 have now been synched with changes from the Stable FA v2.3 on the release of FA v2.3.23. Further changes have been committed to the Unstable branch. This set of changes discerned since last reported pertain to this Hg snapshot.

The error reported in the 22nd post in this thread is still present in this snapshot.

The error in the sql/en_US-demo.sql for field definition is now rectified and the demo CoA installs correctly. The CoAs still have redundant indices - the devs have been informed.

Typos:
jiurnal => journal in comment on line 156 in sql/alter2.4.sql
multiply => multiple in comment on line 195 in sql/alter2.4.sql
hiddn => hidden in comment in line 96 in includes/ui/ui_input.inc

SQL Changes:
Improved journal trans: added currency support, tax and source document date and allow multiple customer/supplier allocations to single journal transaction:

New table 0_journal added - full support for any journal transaction
- no demo CoA entries as yet
- populate with:

INSERT INTO `0_journal` (`type`, `trans_no`, `tran_date`, `reference`, `event_date`,`doc_date`,`currency`,`amount`)
 SELECT `gl`.`type`, `gl`.`type_no`, `gl`.`tran_date`, `ref`.`reference`, `gl`.`tran_date`,
   `gl`.`tran_date`, `sys_curr`.`value`, SUM(IF(`gl`.`amount`>0,`gl`.`amount`,0))
 FROM `0_gl_trans` gl LEFT JOIN `0_refs` ref ON gl.type = ref.type AND gl.type_no=ref.id
 LEFT JOIN `0_sys_prefs` sys_curr ON `sys_curr`.`name`='curr_default'
 WHERE `gl`.`type` IN(0, 35)
 GROUP BY `type`,`type_no`;

0_cust_allocations.person_id field added and made part of unique key
0_debtor_trans.debtor_no populated into 0_cust_allocations.person_id

0_supp_allocations.person_id field added and made part of unique key
0_supp_trans.supplier_id populated into 0_supp_allocations.person_id

Added memo, usage fields to Quick Entries:
0_quick_entries.usage field added as a description field to denote where it should be used
0_quick_entry_lines.memo field added as a description field

Tax algorithm handling on supplier side is reverted as impractical:
0_suppliers.tax_algorithm field removed
0_supp_trans.tax_algorithm field removed

0_sys_prefs has a tax_algorithm entry default for customers only
includes/sysnames.inc has:

$tax_algorithms = array( 
 TCA_LINES => _("Sum per line taxes"), 
 TCA_TOTALS => _("Taxes from totals")
);

and is used in function get_tax_for_items() defined in taxes/tax_calc.inc

0_trans_tax_details.reg_type TINYINT added (0, 1 or NULL in the demo CoA data) and is populated with:

UPDATE `0_trans_tax_details` reg
 SET reg.reg_type=1
 WHERE reg.trans_type IN(20, 21); -- ST_SUPPINVOICE, ST_SUPPCREDIT

UPDATE `0_trans_tax_details` reg
 SET reg.reg_type=0
 WHERE reg.trans_type IN(10, 11); -- ST_SALESINVOICE, ST_CUSTCREDIT

New defines in includes/types.inc:

// tax register type
define('TR_OUTPUT', 0); // sales
define('TR_INPUT', 1); // purchase

0_gl_trans.type_no field definition in sql/en_US-demo.sql now stands corrected

Theme and cleanup changes:
Code cleanup for standard themes ported from FA 2.3 but inter-theme renderer.php files do not yet have their whitespace synched.
General code cleanup and HTML 4.01 compliance ported from FA 2.3 - some tag endings "/>" now become ">" whilst certain tag attribute values are quoted.
Improved error messages in transaction voiding
Sales invoice voiding is blocked when sales credit was issued against the invoice.

Class sys_prefs Method renamed:
$SysPrefs->refresh_company_prefs() => $SysPrefs->refresh()

New functions in UI:
tab_opened($name, $tab)
tab_closed($name, $tab)
tab_visible($name, $tab)
display_caption($msg) to display in <caption> tag added

//Confirm dialog to be used optionally in final form checking routine.
//Displays warning conditionally unless it was displayed
display_confirmation($msg)

New gl function for counter party name:
get_subaccount_data($code_id, $person_id)

Functions moved:
function write_journal_entries(&$cart) moved from gl/includes/db/gl_db_trans.inc to gl/includes/db/gl_journal.inc with single argument
function void_journal_trans($type, $type_no, $use_transaction=true) moved from includes/db/gl_db_trans.inc to new file gl/includes/db/gl_journal.inc

New file gl/includes/db/gl_journal.inc added

Now officially part of 0_sys_prefs table in CoA:
bcc_email
alternative_tax_include_on_docs
suppress_tax_rates

grn_clearing_act
default_receival_required
default_quote_valid_days
no_zero_lines_amount
show_po_item_codes
accounts_alpha
loc_notification
print_invoice_no
allow_negative_prices
print_item_images_on_quote

Theme fix for cool and default themes that still refer to the now defunct variable $allow_demo_mode along with white space synch is attached herein. The devs have been notified to make the necessary change.

FA v2.3.23 stable has been released and it's updates have been merged into FA v2.4 dev repo and some more fixes incorporated into the latter.

Use GRN - Goods receival note. It is designed for such imports.

Create a database for FA to use.
Create a MySQL user for FA to use to access the FA database created earlier (set all privileges for the user to access the db).

Files and Folder permissions for the FA fileset should be readable and writeable by the web server user.

Choose the settlement currency for the vendor.
Get an exchange rate entered for the date on which you book the import.
Create the direct sales invoice and a proper Goods Receival Note (GRN) for it.
Then make payment entries for it and book the expenses for the purchase.

Are you using OpenMiracle? This is the FA Forum.

Take the latest FA snapshot from the official Git Repo.

Read the FA Wiki..

Purchases => Supplier Inquiry - last column in searched page.

This can be done using the the Non Field DB Data method used for Bin Location in Inventory. Just put in an optional piece of text like "TID#1254352" into the memo_ field and have it parsed and used like the BinLoc pseudo field in Inventory. This would indicate your unique Tax ID number 1254352.

It can be added in the address of the Customer if needed.

The Non Field DB Data concept may also be used for both screen form and report requirements to modify existing ones as desired.

Module is the best way to go in general. Where a report needs to be modified for use in all it's instances in the same company, then it would be better to keep the modified version in company/#/reporting/repXXX.php so that it is used when the appropriate report in the FA menu system is called. This is valid only if there are no extra parameters to be passed on from the report request form. If you need more form fields than are there in the default report request form, then make a module of it.

Give me an example of extra field you would want in the gl_trans table and you may be able to accommodate it elsewhere using the Non Field DB Data method explained in the wiki.

Custom modules for complex requirements can have their own tables linked on a 1:1 or 1:N basis with the core FA tables. This way, when an FA upgrade occurs, you will not be left standing high and dry.

Do you want to make it positive inventory only? Do you want to avoid recalculation after switching back from Allowing negative inventory? Then manually set the value in the sys_prefs table and config.php file.