Search options (Page 3 of 5)

I'd like to raise this issue again as I spent some time last quarter reconciling all of this against the GL. Now I know FA gets the maths right!

This bit on the Wiki makes sense and is how it should be done.

7. So per 01/31/2010 we would enter a JE where we empty the Tax Accounts and counter book them on the Accrued Tax Account.
8. Now, when you pay the Tax via Bank Payment, you debit this Accrued Tax Account and your bank account is credited.

However, the system seems to get out of step as if you raise a journal entry against the tax accounts as it adds a tax transaction for the journal in the back end. If there is a journal, it is either a clearing entry as described above or it is to fix an error.

After my reconciliation, I think journal entries against the tax accounts should be exempted from reporting on the tax report or there is a flag provided to enable this. I should be able to do my final tax check after the balance is sitting in the Accrued tax Account and there is no balances in the tax accounts and this amount should agree with the tax report. Then I know I have done the complete job correctly.

If it is an error, (eg. may be I posted a sale as tax exempt when it was taxable and I am obligated to remit a portion of my sales), I would be manually recording details on the reports to demonstrate why the error needed to be corrected to support the journal entry. This scenario may mean there is a case to add an entry to the tax report if one side of the JE is against a sales account, but that may be a bit more complicated to implement.

If there is such a feature to enable excluding JE's from tax reports , please let me know as it would make life easier for me.

Rod

Just a tip for you here. I ave added a period to some of my default groups so the sort to the top of the list. More for Customer groups. eg. I use ".Retail" not "Retail"

Mesjoggah, can you expand on what you to achieve?

I am keen on this as well and hope to eventually have full integration between a Joomla Virtuemart store. Replicating users from Joomla to FA would be part of this process so I might be able to assist in some way.

I looked at doing this today too. I found a link somewhere that suggested it be done in the .htaccess file in the /facc folder by adding this code:

RewriteEngine On 
RewriteCond %{SERVER_PORT} 80 
RewriteCond %{REQUEST_URI} facc 
RewriteRule ^(.*)$ https://www.domain.com/facc/$1 [R,L]

This worked for me and took all of 2 minutes to do but if somebody could outline the pros and cons of using .htaccess v's the other approaches shown, I'd appreciate it.

Rod

Craig, You are on to me! You have found the tool I spoke of that is part of XPDF which lives here:
http://www.foolabs.com/xpdf/
The syntax of this command can be found here:
http://linux.about.com/library/cmd/blcmdl1_pdftops.htm

I have seen the open source XPDF tool bundled into high end graphics conversion software so it is pretty robust.

I think your Brother is running a buggy third party emulation of Postscript which does not support native PDF rasterising so it is failing. Best postscript support comes from the genuine Adobe PS3 Raster Image Processor (RIP), but RIP offerings from Harlequin and Jaws are also excellent. Look to see if PCL can be disabled on the Brother as it is possible the Auto sensing gets it wrong and trys using PCL incorrectly.

I would recommend output is created using the -level2 switch which will generate Postscript Level 2 code that is more likley to be parsed on a wider variety of output devices.

I can't see why pdf could not be spooled to disk by FA using the and then the resulting PS file sent to a printer.

I would suggest that the PDF to PS conversion  and PS job submission be separated from FA and be activated by a separate monitored "hot folder" processing system. That way, all that  FA needs to do is to write a PDF file to a folder and not display it on screen and this external system takes over. If you have a dig on some of the PDF communities like PlanetPDF, you will probably find a tool that does this for you.

POSTSCRIPT
Postscript was the precursor of PDF but was an interpreted language so it needed to run the whole program before you could see the output. Adobe saw the need for robust portable document format and responded by developing the object oriented PDF specification. The great advantage of this is that everything in the document is treated as an object and the tail of the PDF includes an index to the page objects which in turn have pointers to the objects on the page. This allows post processing of and navigating through PDF files very efficiently. I would not call PDF a wrapper around Postscript but because of the common heritage, Postscript can be converted to PDF very efficiently. Acrobat Distiller is basically a POstscript RIP that outputs PDF files rather than raster images for printing.

And here is the 2.2 bug report. with updated files
Issue #215: http://mantis.frontaccounting.com/view.php?id=215
Has there been a regression? I have not revisited this to check it still works.

An interesting discussion, but it seems to me the example with the pallet is mixing Retail/Wholesale pricing with volume discounts.

Maybe the addition of volume discounts should be put on the agenda. Maybe a product/sales group pair has another table(s) with entries like:
qty 0-100  $120
qty 101-500 $100
qty 501-1000 $90
qty 1000-99999 $80

Of course the existing functionality around % or $ could still apply.

What version?
There was a bug at one time (2.2.6 I think) that did not print the shipping address. I modified the report to fix but I think the dev team resolved the bug another way.

Once I ifxed it, I could enter customer's address in Shipipng address and supplier drop shipped for me no problems.

Hi Guys, just catching up on the latest FA developments and this sounds interesting. I am pretty sure (witout reading the UK Links) that if you fix this for Cash Accounting of VAT, it will also satisfy the Cash accounting requirements for Australian GST.

I resigned myself to running my GST in an Accrual basis so I think this will be a good extension

Sorry, it has taken me a while to get to this as I was away for a week or so but I have done as you asked.

I think this would be a good idea. There is quite a bit of unnecessary wok in FA where you have to make supplier payments and customer receiptsand then subsequently allocate the transaction.

While you are at it, could you also consider being able to allocate a receipt (deposit) to a sales order for customer transactions. It sucks having to wait until an order s delivered and invoiced before a customer deposit can be allocated against the transaction. That process is very similar to what is proposed for PO's above, just on the other side of the ledger.

I have a lot more deposits on sales orders than prepaid purchase orders.