4,226

(13 replies, posted in Setup)

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

4,227

(24 replies, posted in Accounts Payable)

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

4,229

(1 replies, posted in Setup)

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

4,230

(5 replies, posted in Items and Inventory)

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

4,231

(5 replies, posted in Items and Inventory)

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

4,232

(20 replies, posted in Accounts Receivable)

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

4,234

(13 replies, posted in Setup)

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

4,235

(13 replies, posted in Setup)

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.333

and the attachment may look like this:
4a6ef175e16b2.pdf (could this be a problem?)

/Joe

4,236

(13 replies, posted in Setup)

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

4,238

(2 replies, posted in Wish List)

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

4,239

(2 replies, posted in Installation)

Have you tried to set the $go_debug flag in config.php to 1. This will capture the errors/warnings.

/Joe

4,240

(2 replies, posted in Dimensions)

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

4,241

(1 replies, posted in Misc. Charts of Accounts)

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

4,244

(1 replies, posted in Reporting)

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