Search options (Page 4 of 6)

Waverider, there's nothing to stop you renaming company 0, and reloading SQL data with 0_ as a prefix if you really want to get rid of Training Company. Having said this, as mentioned above, there are benefits to keeping Training Company (namely, testing and learning).

Don't forget you need never see Training Company if your user profile is set to use a certain company as the default - it can just hang around in the background.

Personally, I run separate test and production databases because I don't want to back up training data and include it in the production backup. It's also less confusing for me when I'm in phpMyAdmin looking around.

Hi tomhallman

Your idea sounds OK for dimensions, but I think it's a bit risky for accounts to be tagged - mainly because the integrity of the DR/CR balancing transactions is compromised eg.. user enters DR/CR 3 months ago into accounts with different tags. You then run a report, it picks up the DR but not the CR = invalid report. This is a pretty serious problem to introduce into a ledger based system! I think this is the point Joe raised.

Back to the business need though - I can see a need to report on selected items - I'm just not sure tagging the G/L account is the right way to achieve this. Perhaps you could make your implementation, do some reports, and let people think about it some more when they've seen what it could do.

cheers
Pete

Hi Janusz - OK will start looking at the 2.2 version for this change.

(By the way, I sent a Joe a new copy of the Australian chart of accounts today (it's generic for any service company anywhere really). I have updated the chart of accounts to reflect the new standard accounting equation you guys put in, so the structure should be right for future versions. Hope to see it replace the old Australian in Chart of Accounts downloads soon, or I can send it to you Janusz)

Are you asking a question?

If so, "Error: Cannot create database" sounds like you don't have authority to create databases in MySQL - you need to check your user id and ensure it has CREATE DATABASE authority. This is done in MySQL, not FrontAccounting.

It looks like you don't have a valid account setup on MySQL for your database.
Make a valid account in MySQL for your Frontaccounting database, then make sure the user id and password appear correctly in the file config_db.php.

The second error message is a consequence of the first.

Hi Janusz
Back again after a bit of a break from FA:.....did you put this tax change into the 2.1.5 or would you still like me to look at it? Also, I responded to someone's PHP 5.3 issue here just a minute ago: maybe we could put a posting up clearly that PHP 5.3 is unsupported (I'm presuming you guys are on 5.2, I used 5.3 but stopped after an hour of debugging, and downgraded back to 5.2).
Cheers
Pete

Just a suggestion - did you ensure your category existed first?

hi jonnyx
With your proxmox installation, there will be a default .sql file that is loaded up for your company. You could check the table 0_users or 1_users, and get the correct user id from the first column: user_id.
Then - you also have an MD5 hashed password  in the 'password' column. Unfortunately, you probably won't be able to crack that, however, you could check the contents against some known passwords - in the Sourceforge FA download sql file for instance, or you could even try (if on a *nix box)
md5 -s testpassword
Try a few passwords to see if you get a match against what's in the original table.
Pete

Hi ITCynic and Joe

I spent a spare 30 minutes today looking into this date format problem (I'm going to customise it for faster data entry for me), and can shed some light on it for you to either fix it, or workaround it. FA uses an interesting javascript cache technique to reflect user preferences by using code that actually creates a new code file - in this case date_picker.js which lives in
/company/x/js_cache  (where x is your company number).

When you change your user date format in the display_prefs.php screen, the system updates the $_POST variable with your requested format and other changes you want. A few other steps are run, and then /includes/ui/ui_view.inc actually writes out a NEW javascript file that includes the code for the date picker, including the order of days and months. This file goes in your /company/??/js_cache folder, replacing the old one. So... you end up with a new javascript file (date_picker.js in this case) that matches your formatting preferences.

ITCynic, it sounds like your date_picker.js file is NOT being copied into the  /company/x/js_cache directory properly. You can see if this is occurring by checking line 51 of the date_picker.js file: 

if(dateField){try{var dateString=new String(dateField.value);var dateParts=dateString.split('-');selectedDay=parseInt(dateParts[0],10);selectedMonth=parseInt(dateParts[1],10);selectedYear=parseInt(dateParts[2],10);}catch(e){}

(this is part of the 'show' function which takes your on screen inputted date, and updates the popup when you click it).

Note this line should contain your separator 'split('-') AND the right offsets for day and month that come from the text input box screen. In the case above, Day is element 0, month is element 1, representing a 31-12-2009 style date.

Your problem might be caused by write permissions on the directory, or some other defect in the .js file copying process.

If you plan on sticking to one format,and one separator, you can overcome your problem by just editing this date_picker.js manually, replacing line 51 with the one above (assuming you want 31-12-2009 format). Try this and let us know how it goes. It does sound like a problem unique to your environment though, as everybody else is creating the date_picker.js file and copying it successfully.

Cheers
Pete

PS. HAHA - I just missed Joe and ITCynic's updates - oh well, I've learnt about the date picker and will let the forum know when I've updated a new one I want that will let you type in
12032009
120309
12-03-09
12-3-2009 etc.

I find the digits only way very quick to enter data.

ALL browsers have a host of discrepancies/bugs when handling javascript. The engine's have previously been the last thing the browser developers have worried about.

In response to ITCynic, I support the developers 100% in the way they prioritise work. In your case, the best guess is this is a javascript problem with the date picker (I looked at the PHP code too), and I'd prefer they didn't waste time trying to accommodate browser issues for one country (so far). If you don't believe javascript engines are crappy, ask yourself why google has spent millions developing a framework that tries to integrate them!

I have a totally different view to ITCynic on the way bugs are handled in FA. Genuine, reproducible and significant bugs get almost immediate attention off these guys - more than any I've seen in any other software, commercial or otherwise. In regards to help, I think the guys also do a sterling job - to those who can communicate their problem and understand accounting adequately. To clueless people on here who ask questions like: "can someone tell me how to interface FA to xxxx payroll" etc, or "can someone do all the hard work so I don't have investigate or learn about my problem" I would encourage the guys to keep giving them polite, but short shrift. This is open source software - you get what you put in.

To be blunt ITCynic, come back when you understand and have debugged the PHP code, otherwise make an offer to pay someone to sort out the problem for you rather than criticise the developers because they don't do it your way . Your experiences with dates in non-browser applications you've used since Y2K are irrelevant - as I said, javascript engines are awful. A more practical piece of advice for you would be to replace the existing javascript date picker with another one (there are heaps of them out there) - not too difficult, and will narrow down the problem for you.

Actually Hameed your accounting interpretation of Gross Profit Margin is wrong.
It only includes costs directly attributable to producing a single additional unit - usually materials and often labour. In most systems, COGS accounts are flagged as such so this calculation is done correctly.

Overheads are NEVER included in gross profit margins.

Note to Joe/Janusz - it's appropriate to include any COGS expenses, but overheads like lighting, electricity etc. ie. anything not directly attributable to creating an additional single unit should not be included in a Gross profit margin reporting.

THe original poster might be mixing up Net Margin - this is never done at a product level, but across the business, and includes all expenses.

This site has good, international definitions of most accounting terms:
http://www.investopedia.com/

Pete