Search options (Page 191 of 247)

The individual language files are also available with all extensions in my Unofficial GitHub Repo.

Check the FA Support Page in the Wiki for a list of geographically dispersed FA support entities.

Is it because delivery date is hardcoded as yesterday, current or future date and was considered not necessary to be editable?

@geoffreywalton: Thanks for the checkout.

The payment_terms sql typo stands corrected as also the heading for the persons import para.

AUTO_INCREMENT=@person_id also does not work. I too actually used only hardcoded values and assumed that expressions would be acceptable. The wiki article now stands corrected with an assignment of zero (0) value that automagically acquires the correct value.

Which fields in which statement(s) is not in the same order as those in the FA table definitions? Attached one instance that differs from your post.

Being a pure SQL solution, skipping the header was not an easily accommodate choice.

The reason why the surname was not included was that during creation of a new customer in FA, the branch gets auto populated with the same value as the Customer Name for the "name" field and blank for the "name2" field. These sqls were designed to mimic the default FA behaviour. Subsequent edit of the branch and the associated contacts is where the "name2" can be added in. This will be evident when you import multi branch customers where an extra HQ branch is created first where no surname (name2) is envisaged, but rather a space for accommodating longer client company names. This can however be mitigated by selectively using the name2 field for the extra branches added alone.

No CSV import was done in phpMyAdmin - only tsv (tab separated values) was used in LOAD DATA LOCAL constructs. The usage of linefeeds (\n) especially in the addresses will need to be checked.

The currency used is also only the default company currency and individual cases can be SQLed in or manually edited if only a few.

The first iteration of sqls was to add in the customers one by one, take the last inserted id and then progress to the next table - it was very slow and painful (SAP!).

The last 4 fields of the temporary cust_list table are declared as DEFAULT NULL as they will have to be filled in manually (or possibly with some more sql magic) instead of by some tsv import, though in my case I manually did it in excel and then imported it.

The debtor_ref and branch_ref fields are VARCHAR(30) fields that have to be manually prepared to be unique and meaningful generally alphanumeric being similar to the actual Customer / Branch names without spaces and special characters (hyphens and underscores allowed) since the dropdown boxes have limited width onscreen.

Using a MySQL client like SQLyog (community edition is free) makes it a lot easier.

Spending your Christmas / New Year holidays working for a brand new FA release version is indeed a fine gift to the FA Community.

Thankyou indeed!

This will hopefully avoid having to support multiple versions and focus resources in maintaining just one really good version going forward.

Redundant Indexes removed in FA v2.4 in my unofficial GitHub Repo and shown for v2.3 in attachment.

This has been addressed in an earlier post and needs a dynamic assignment based on collation of existing database / table.

Typo crept into line 14 of your hooks.php:
additional => additonal

Since an unrelated file got edited, you may want to see if the relevantly changed files have issues.

Key changes seen in your v1.2 as opposed to the v1.1 available in theFARepo as import_paypal-2.3.10-2.pkg (haven't see the import_paypal-2.3.10-3.pkg yet) is the removal of the paypal_fee_act field - any reason for commenting them all out? Also the log messages pertaining to memory have been commented out as well.

Line 71 of import_paypal_update.php still refers to the variable $paypal_fee_act as global and probably not used now.

The main purpose of this version was to fix only the filename format alone.

It may be possible that you edited an older set of files.

Do you have it on github?

The table #_cust_branch has 2 address fields:

1. br_address - used for Mailing Address
2. br_post_address - used as Billing / Shipping Address -> this gets into the address column in credit invoice form and shows up in the "Delivery to" address in the Invoice.

Just tested with FA 2.3.22 + updates in Direct Invoice.

Attached is the Customer Branch Screenshot with fields and form elements for these addresses.
Sales => Maintenance => Customer Branches

In general, PO Box are used for small postal "mail" like Invoices and Orders.
In the same vein, "Delivery / Shipping" are to physical warehouse / sales area addresses.