Search options (Page 166 of 247)

@joe: Thanks. Wiki-ed it.

@seahawk: Thanks. Wiki-ed it.

@seahawk: Thanks. Wiki-ed it.

@joe: Thanks. That was a nice fix.

FA v2.4 is now fully installable and the reports display with correct paths in Windows thanks to Joe's commit reverting to FA v2.3 config variable $comp_path assignment.

The above commit now means that relative path addressing listed in the 22nd post in this thread is no longer valid.

Actually Paypal Import Transactions is more of a payment transaction basically and not an invoice generation / customer creation transaction although the code sports it. The Customer and their Invoice should generally pre-exist for a PayPal transaction to effect payment allocation to it. It is therefore no wonder that no transactions are related to existing customers and is  either not imported at all or is imported as an orphan record. You can try to create the customer and invoice manually if they do not exist and then manually allocate / edit allocation of the payment.

Sounds great. Regular Backups with a manual computing journal of activities and comparison of the backups will help during the skilling-up phase. How do you handle wrong entries - using new contra entries or just making changes in the raw db tables?

Making the FA period just 1 month instead of a full fiscal year or a dummy accounting year shifting one month forwards each month on restoration will help simulate closing month by closing dummy year.

The devs can put out a list of new features in FA 2.4 that will help users in deciding if and when to update.

If you have a backup prior to the paypal imoprt, then revert to it.
Then manually do the transactions necessary for 1 paypal transaction.
Take a backup.
Now revert back to previous db state.
Now import the same transaction using the import_paypal extension
Take a backup again.
Now compare the last 2 backups using a diff tool like WinMerge and see what is different.

The fact that the SQL executed without error incicates that the absence of transactions is a functional application error. Need to also contact the module author.

Try to execute the sql on your database in some MySQL client like SQLyog or phpMyAdmin:

SELECT 
   trans.*
  ,ov_amount+ov_gst+ov_freight+ov_freight_tax+ov_discount AS Total
  ,cust.name AS DebtorName
  , cust.address
  , cust.curr_code
  , cust.tax_id
  , com.memo_
  , shippers.shipper_name
  , sales_types.sales_type
  , sales_types.tax_included
  , branch.*
  , cust.discount
  , tax_groups.name AS tax_group_name
  , tax_groups.id AS tax_group_id  
FROM debtor_trans trans
  LEFT JOIN comments com ON trans.type=com.type AND trans.trans_no=com.id
  LEFT JOIN shippers ON shippers.shipper_id=trans.ship_via
  , debtors_master cust
  , sales_types
  , cust_branch branch
  , tax_groups  
WHERE trans.trans_no=''
  AND trans.type='10'
  AND trans.debtor_no=cust.debtor_no 
  AND sales_types.id = trans.tpe
  AND branch.branch_code = trans.branch_code
  AND branch.tax_group_id = tax_groups.id;

and see what results you get.

Unless you used no Table Prefix, it seems to be missing here.

Wiki-ed the info.

Which version of FA are you using. There was a commit to rectify a similar (or same) issue a few months ago.

Do you have the dejavu.php file in your FA webroot?
If not, get it from the frontaccounting.com downloads section.

Read the related section in the wiki.

dejavu.php missing - TCPDF Font Failure

• Download dejavu.php

• Extract contents to reporting/fonts folder

• This is the default unicode font when none are defined

• Can change this font at around line 161 in reporting/includes/class.pdf.inc