I have no idea why this is not workning. Hopefully somebody in the community can help us.
You could make a test using the included class /reporting/includes/class.mail.inc and see if you can find something strange.
/Joe
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 joe
I have no idea why this is not workning. Hopefully somebody in the community can help us.
You could make a test using the included class /reporting/includes/class.mail.inc and see if you can find something strange.
/Joe
You shouldn't have any problems with that. Check that the Items have the correct Item Tax setup.
/Joe
See my answer to a similar topic in Setup.
/Joe
You are not doing anything wrong. The VAT is calculated inside FA. You will have some pennies calculated wrong in these cases, but it shouldn't bother you. It would be evened out over the transactions and most Tax payments/receivals are truncated to zero decimals.
/Joe
You don't have to do anything specific to have the correct calculation. Just mark the Sales Type as Tax Included, then everything is done automatically. Try for yourself on the demo company.
/Joe
Normally if tax is included, you would print the amount of tax that are included, for those that need this information. If you don't want to print this information on the invoice, then you will have to remove the line in the report /reporting/rep106.php.
/Joe
In the Company Setup, on Setup tab, you can mark the checkbox 'Search Customer List'. Then you can use the space bar to start the search (inside the combobox).
/Joe
You can reverse this transaction by voiding it. Select the transaction type and number. You get an option to look at the transaction before voiding it.
/Joe
Hello again,
We are about to ship the release 2.1.4 (only bugfix release) in a couple of days. We have improved the email letter a bit and given the attachment a more normal description. Hopefully it helps.
/Joe
Hello again,
I have done some research on this. If the recipient of the email has been delivered through a mail forwarder it seems to hang up in the first email spam filter and doesn't get forwarded at all. Will you check that too, jackel7007.
To avoid our emails with attachments to be catched by spam-filters we probably need to refrase the emails.
Anyone have any good ideas here?
Now it looks something like this:
Dear Sirs Ghostbusters Corp.,
Attached you will find Order no. 56
Kindest regards
Demo User
Training Co.
Address 1
Address 2
Address 3
delta@delta.com
(222) 111.222.333and the attachment may look like this:
4a6ef175e16b2.pdf (could this be a problem?)
/Joe
Have you tested to see if the email has ended up in the receivers spam filter? Some spam filters are very 'cruel'.
/Joe
The development team doesn't have any plans for integrations, but there have been several plans to build semi integrations as modules. I think you can find them in this fofum.
/Joe
Sure, we are doing our best.
In release 2.2 we have removed some redundant transaction types from the database table 0_sys_types. Instead we use translatable constants from the file /includes/types.inc.
/Joe
Have you tried to set the $go_debug flag in config.php to 1. This will capture the errors/warnings.
/Joe
The reason for removing this from the dimension overview is that these transactions can get really huge. Therefore we are compacting them on a per account summary.
If you want to see a detailed inquiry, use the Gl Account Inquiry and filter by dimension.
If you want to see a detailed inquiry, you can also use the report GL Accounts Transactions. Select the first account and last account in the lists. Then filter by dimension. This way you will get a detailed report.
/Joe
Hello,
The last value in 0_chart_class is a reference to a system defined type value (from release 2.1.3). 1 = assets, 2 = liabilities, 3 = equity, 4 = income, 5 = cost of sales, 6 = expenses.
0_chart_master: 101 is a reference (foreign key) to 0_chart_types. 0 is a value for inactivity (normal 0).
0_chart_types: 4 is a reference to the class id. 1 is a reference to another chart_type (sub-type). You can have more levels, but this is not necessary. The default value is -1.
/Joe
The link is:
/Joe
ok, thanks Tom,
/Joe
No, it is not planned. You can export a csv report from Excel/Open Office Calc.
/Joe
Look into the X_debtor_trans table to see if there are types 1 with a minus sign in front of the amount. If so, then remove the minus and download the new files from CVS.
Yes it might have got you trouble, because these payments (with minus sign) didn't show up in the allocation list.
/Joe
Hello slax,
I am afraid that you have run into a bug. When the Bank Payment was used to pay a Customer (normally you use this for supplier payment) the amount was saved with a minus sign in the X_debtor_table (where X is the company number if you use table prefix).
As a side-effect you couldn't allocate this customer payment later, while is did not show up in the allocations.
This routine works OK the other way round (using the Bank Deposits for a Supplier Deposit), so no problem here. But,
The reports Customer Balances and Supplier Balances presented the wrong balance for this odd operations.
All this is now fixed in the CVS Main Repository. You can download the following files:
/sales/includes/db/cust_trans_db.inc - revision 1.7
/reporting/rep101.php - revision 1.7
/reporting/rep201.php - revision 1.7
Unfortunately the records are already saved in the X_debtor_trans table with this minus sign for trans type 1. You can use phpMyAdmin to edit your database, table X_debtor_trans and select View and find the records for trans type 1 and remove the minus sign from the amount.
Then everything will work ok.
/Joe
Both the Customer Transactions as well as Supplier Transactions are positively, that is invoices are displayed as debits (charges) and payments/deposits are displayed as credits. The reason is to have a uniform way of display.
/Joe
Maybe we can attract Tom to help us with this. He modified the Import Customers to also work with osCommerce. The developers are very busy with the 2.2 release.
/Joe
Well, I hope somebody using ubuntu can help here. I have a Windows developing environment.
You might try to download the frontaccount-2.1.3.tar.gz instead of the zip version. This version has been assembled by Janusz. He is using Linux as development environment.
And install this instead and extract the strings using this new installment. Maybe it is better.
And maybe somebody else can advise us here. I haven't heard about this line end problem before.
/Joe
Forgive me, I am not following you exactly. The only thing that is in transit here is the money. You haven't received anything until you have done your second payment.
This is how I would treat it:
1. PO to supplier, with correct required dates.
2. Payment 1 and 2 done to the supplier on the two dates.
3. Enter the receival per 30th jan and the supplier invoice. The receival and invoice could also be entered at once, but with correct future dates.
/Joe
FrontAccounting forum → Posts by joe
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.