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
Please review the0002779: Hardening against directory traversalpatchprovided and include it if found fit.
Found that it has been fixed in release of FA v2.3.20 dated 2014-03-10 but the status was not changed to resolved in the Mantis bug tracker as were quite a few more assigned to janusz.
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
The above change occurred when going from import_paypal-2.3.10-2.pkg to import_paypal-2.3.10-3.pkg whilst remaining in the core v1.1 with no other changes between these versions. Practically all extensions have been affected by this change probably introduced when compiling the pkgs.
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?
Works now. Thanks.
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.
Should this not be extended to not just Polish but even when no session encoding is present like in the default C or null encoding?
The file sales/includes/db/branches_db.inc has the following function:
function get_sql_for_customer_branches()
{
$sql = "SELECT "
."b.branch_code, "
."b.branch_ref, "
."b.br_name, "
."p.name as contact_name, "
."s.salesman_name, "
."a.description, "
."p.phone, "
."p.fax, "
."p.email, "
."t.name AS tax_group_name, "
."b.inactive
FROM ".TB_PREF."cust_branch b "
. "LEFT JOIN ".TB_PREF."crm_contacts c
ON c.entity_id=b.branch_code AND c.type='cust_branch' AND c.action='general'
LEFT JOIN ".TB_PREF."crm_persons p on c.person_id=p.id,"
.TB_PREF."areas a, "
.TB_PREF."salesman s, "
.TB_PREF."tax_groups t
WHERE b.tax_group_id=t.id
AND b.area=a.area_code
AND b.salesman=s.salesman_code
AND b.debtor_no = ".db_escape($_POST['customer_id']);
if (!get_post('show_inactive')) $sql .= " AND !b.inactive";
$sql .= " GROUP BY b.branch_code ORDER BY branch_ref";
return $sql;
}The above function is called only in sales/manage/customer_branches.php.
The #_cust_branch table already contains a contact_name field that does not seem to be used here in FA now.
The name field from the #_crm_persons table seems be to be the preferred source of Contact Name in FA.
Is this the intended design?
If we now refrain from populating the #_cust_branch table's contact_name field, then it's use in the reports will suffer.
The #_cust_branch.contact_name field is used in rep103.php and rep106.php still in get_customer_details_for_report() in the former and in GetSalesmanTrans() and print_salesman_list() in the latter.
You must decide on your webroot path and set them in your apache conf file and restart your webserver.
The extensions are available in my GitHub repo for manual inclusion for offline use - slightly outdated by a one point release in some pkgs as on date.
I have just uploaded a tutorial on Manual Import of Customers into FA.
It can be studied with the help of the ER Diagram available in the Wiki.
Thanks to Rick Miller of Lone Star Tool who provided test data and insight and @joe for shipping address location that made this possible.
Updated on 2014-12-09 to address the Shipping Address issue and now includes TaxNum population.
Thanks, will try it out.
Still not available.
Check your apache conf / vhosts conf for deny/allow rules
if the webroot is /var/www/frontac
and the webserver user:group is www:data:www-data
then:
WEBPATH=.var/www/frontac
chown -R www-data:www-data ${WEBPATH}
find ${WEBPATH} -type f -exec chmod 644 {} \;
find ${WEBPATH} -type d -exec chmod 755 {} \;[ Quote ] -> [ Order ] -> Delivery -> Invoice
That's right. Waiting for @joe to clarify way forward and integrate a fix.
Thanks Joe.
Wiki-ed it and cross referenced it as well.
A possible search and replace using the QUOTE() function of MySQL may be one solution. Another would be a search and replace of such known entities in the most affected fields or in the db_escape function itself. This is also the reason why the currency symbols stand as "?" in the CoA sqls.
Where in the Branch should we put in the default Shipping address? Is Shipping Address synonymous with Billing Address as far as the branch is concerned?
All customer / branch forms show Mailing Address and Billing Address only and there is no Shipping Address in them. The Shipping Address only appears in the Invoice forms.
For a new or existing Customers, where can we enter their default Shipping address?
New Customer data entry shows Mailing Address and Billing Address only.
Change ownerships of all files to your web server process owner (www-data:www-data in Ubuntu/Debian, httpd or apache in CentOS)
Make all folders 755 and all files 644 to start with and disable all .htaccess files and put them back one by one to see what breaks where.
Use the code snippet in:
https://frontaccounting.com/punbb/viewtopic.php?pid=6179#p6179
to check if the "from" and "to" addresses are obeyed or if sendmail is overwriting it with some hard coded entry in the php.ini file.
@joe: Thanks. Just checked the code fully, there is no 'ZONES' and only 'AREAS'.
@dz: Just replace your 'ZONES' with 'AREAS'
When using the inventory import module (items export/import) there will be one entry for each item for each Sales Type and by default, since there is Retail and Wholesale, we land up getting two entries for each item if all prices are populated.
Correcting the material_cost directly in the table could have repercussions in the stock valuation and the dependent contra accounts as well when future FA inventory transactions occur.
Check for file / folders permissions and ownerships and webserver (apache) conf and .htaccess file issues.
FrontAccounting forum → Posts by apmuthu
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.