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 tm
That sounds a lot like what any e-commerce software does. (Generate orders and keep track of order/invoice history.) Of course you would need to transfer the order data to FA regularly, and also keep the products (and possibly stock levels) in sync, but that might well be justified assuming it increases sales.
If you only need to be able to make reports available, you could implement your own simple frontend to FA's database. (With your own access control layer.)
If the compiled files work under Windows, then I would work from there. Methodically. The version of poedit (?) I found in the Ubuntu repo was broken, and the later versions wouldn't build under 12.04. (It may work better with later releases, but I can't be bothered with the bleeding edge anymore.) Anyway, I suggest you leave that out for now, rather than confusing yourself by introducing more potential error sources.
Start by moving the working files to a fresh (and preferably virtual) Ubuntu server, and make a note of anything you do that gets you closer to a working state. File integrity, locales, file/directory ownership and permissions...
I'm not the developer here, but if I may make a humble suggestion...
There are perfectly good reasons to store binary data in the filesystem, and not as a blob in the database. But there is no reason whatsoever to store a string in a file, when you have a database.
Currently the item id seems to do double duty as a filename field, which is fine if all files are local. And if no item needs to have more than one image associated with it.
Since a URL can point to a local or a remote file, it is clearly a lot more flexible. But then it should be stored in the database. Either as a new field in the item table, or in a new table. The latter allows an item to have more than one image, which would be an improvement in itself. (That part could be added later, if there was already support at the database level for it. And if someone actually needed it.)
If anything is to be merged into the trunk, it should not only be an improvement. It should also be as general and flexible as possible. Duplicating functionality and selecting the appropriate execution paths based on a config file flag may not be the best way forward here.
But fortunately, reading/writing the URL from/to the database should be no more complicated than what you're doing now. And it should be easily handled by an update script. (Just create the new field/table and populate it with the paths to each file in whatever subdirectory the images are currently stored.) The image upload page would need to handle files as well as URL's, but not necessarily at the same time. Initially, you could just overwrite the current entry with the first non-empty field supplied. And later, it could be extended to support multiple images.
So it works under Windows? If so, there could (still) be a problem with the locales installed on the Linux server. Or perhaps an encoding issue? Is the file really in UTF8 format? Could it be that the Windows server is more forgiving about newlines or byte order marks than the Linux one? Or does the file get mangled by an FTP client trying to convert it while uploading in ASCII mode? That could explain why downloading and then uploading a file breaks it.
And if nothing else works, you could always run it on a Windows server... 
I'm not going to turn this into a rant about the translations and the way they are handled. I'll just point out that the lack of responses in this thread illustrates why this area is such a mess.
Now, a few constructive (?) suggestions.
Are the files themselves OK? From my brief attempt at translation, I remember some problems with the po editors I tried. (I'm not sure if the lines were too long or they used the wrong newline characters, but there was something preventing the files from being properly read.)
I don't know if any of this goes into the database, but if so I'd expect it to be confused by data in a different charset. (By the time you install a COA, I can certainly see it being an issue.)
I'm not sure why you'd want to do that. It is a web application, after all.
But if you really need two separate instances, you could have them use the same database. (Assuming that FA handles the locking required and that your database is accessible from outside.)
Updating two databases independently and then trying to merge the changes is going to be a mess.
I did have a similar issue on a local Ubuntu server, where there is a cron job (/etc/cron.d/php5) removing old sessions every 30 minutes.
On Ubuntu (at least) this makes FA's login timeout value largely irrelevant as there is an external script purging sessions according to its own settings without FA ever knowing about it.
I got it sorted by increasing the session.gc_maxlifetime variable in php.ini. (Note that there may be more than one such file, as the main config file can be overridden by an application's own php.ini. And if you have the PHP CLI package installed, it also has its own php.ini. On a local server, with no other PHP applications, you can safely apply the change to all of them.)
I don't know if this applies to the Mac versions, but it could be worth looking into.
Could your server could be purging the sessions too aggressively? Or does your client's IP address change? Apparently that can be the case if you're connecting with a mobile device.
I'm afraid I can't help you there. The files output here are perfectly good Excel files. Well... Good enough for LibreOffice, anyway. Can you get anything out of FA in Excel format? Could there be some library missing?
I did that for Swedish VAT reports, by just querying the database for the balance (at the end of the period) of a bunch of accounts, adding a few of them together and outputting the appropriate figures inside the appropriate XML tags. (The script also creates a balancing transaction to be imported by the CSV import plugin which I use to import daily sales figures. I'm not familiar enough with the database model to suggest how to do this directly in SQL, but if you have the figures you could always do it manually.)
It's a (very) simple php script sending a ridiculous number of queries to the database. But it only runs once a month...
Something like
select sum(amount) from gl_trans
where account = $a
and tran_date => $periodstart
and tran_date =< $periodendshould get you the data for each account, assuming the VAT accounts were balanced at the start of the period. (I ensure that by booking the balancing transaction on the last day of the period. Otherwise you'd need to sum up all transactions of the account from the start of the year.)
Then you can just output the data into whatever format you need.
Xero,
I wrote a small script to fetch the figures directly from the database, without involving FA at all, which allows me to create monthly (Swedish) VAT reports, and also generate a balancing transaction.
The fact that it is done well outside FA may be a problem, but in my case it's rather an advantage since it can easily be run from a cron job. Also, the balancing transaction has to be processed (in my case using curl) by the "Import Multiple Journal Entries" plugin, but that is not an issue since I already happen to use it to import daily sales figures from a web server.
There isn't much "programming" involved. Just send a few queries to the database and assign the results to the appropriate fields, before outputting an XML file. (I'm not at all sure if HMRC will accept files for upload, so you might just want to print/email the report for someone to enter the figures on the website. The same might apply to the balancing transaction, unless you already happen to have some means of importing it. Or feel adventurous enough to insert it into the database yourself. As for me, I was quite happy not to have to go down that route.)
Most of the work is actually mapping your accounts (or combinations thereof) to the fields on the form, so you shouldn't have to be much of a programmer to create something similar. Besides, any language would do as long as it allows you to access a MySQL database. (PHP does have the obvious advantage of running on any server that runs FA, though.)
I'm all for doing it "properly", but this just might point you in the right direction for getting something up and running before that happens.
And, for what it's worth, the wiki doesn't make sense to me either... 
Daylight savings time?
In /includes/session.inc there is a function preventHijacking(), which seems like a good place to start. The second test compares the session's IP to the current connection's.
We used to translate the messages using poedit or similar tools. According to my feelings the problem here is not lack of tolls, but rather lack of translators
.
I'm not sure what we can do to help you with the problem?
Janusz
I once considered cleaning up the Swedish translation, but decided to use it in English instead. (Apparently the poedit version available from the Ubuntu repo was rather buggy, and then even the translations which looked correct turned out not to "line up" with the phrase they were supposed to replace. That was enough to put me off the project.)
Had there been a "translation portal" along the lines spott suggested, I could have changed a word or a phrase without downloading anything and without having to submit a file anywhere. The problem is not so much the lack of translators, but rather the lack of translators wiling to accept responsibility for maintaining a translation.
The current system expects the translator to be a software developer, which obviously limits the number of potential translators available. In fact, any "professional" user (accountants etc.) would have the "domain knowledge" (terminology) required for translating the application. And any literate user would be able to fix typos and spelling mistakes.
Enabling them to do so without commitment would surely lead to better translations.
Has anyone done anymore work on creating a report that can be used to assist with submitting an Australian Business Activity Statement (BAS)?
I would be happy to pay for a module or report that could handle this.
It's neither a "report" in the FrontAccounting sense nor a module in any sense of the word, but...
What I have done for for sales and tax reporting is create a small script to read data directly from the database and fill in the appropriate values in an XML file, which can then be sent to the tax office. Using the same data, it also creates a CSV file with a journal entry to balance the VAT accounts, which can be processed by the "Import Multiple Journal Entries" plugin. (Since I already use that to automatically import sales data from a web server via a daily cron job.)
Depending on your setup and requirements, you might be able to do something similar. The "programming" involved is quite trivial.
Having said that, I would not want to be seen to discourage AlastairR or elax from their work on a more generic module. Keep it up.
FrontAccounting forum → Posts by tm
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.