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 p2409
My point is what are the features commonly used in applied posting FrontAccounting
thx
ad1t
Answer: all of them lol.
If you have a question that can be answered, do some research on the site first eg. the Wiki, then ask it. Pointlessly vague, or lazy questions usually get no response.
Hi Guys
I've just a made a few updates to the Wiki as I was finding out about Items and Item Categories. I also update Quick Entry with a new example. I also updated the Dev section with some info on the config_db.php file. Basically, as I sort out things on my own system and learn about it, I'll update the wiki.
I'm happy to make a few more entries: are there any areas in particular in the Wiki you'd think could benefit most from new info? If you name them, I'll have a go.
Cheers
Pete
You could create two new 'bank accounts' called 'Federal Tax Prepay' and 'Municipal Tax Prepay'.
Then, when processing payments, just allocate the three payments to the three different 'bank' accounts.
The invoice will be fully paid, and you will know from the balance of the prepay tax accounts what you owe the government.
This doesn't involve changing any screens/code.
You don't say what you're trying to achieve here, but there are MySQL database syncing tools available (eg. https:/sourceforge.net/projects/mysqltoolkit). It can get complicated, but syncing is a possibility with this DBMS.
1. You will have to post each item individually. Reconciliation without detail is a nightmare on any system!
2. I would stick to invoices and add line items individually. Unfortunately right now you can't add a reference to each line item, but that feature would be ideal for you if it existed. If you know how, you could modify the debtor_trans_detail table (and screens) to add this custom reference (note) in there. That would help alot in reconciliation.
I'm assuming when you say do it in the "G/L" you mean post journal entries. The benefit here is you can put a note in there with a reference for reconciliation. The downside is .... journal entries are not designed for making standard business transactions with. You could easily break your ledger.
I'm assuming you are the same person who asked this question in another part of the forum.
As you are finding, it's more difficult than just changing the length in one or two places.
Rather than wreck the existing code, my advice would be to actually create a completely new, larger location code field and use that throughout the system.
The other option is to stick to the 5 letter code, but make each letter mean something eg. 4th letter means bin number x.
The last option is pay someone else to do it: it's a specific mod though, I don't know if many people would be interested in sharing the cost with you.
Check the 'Download - Chart of Accounts' section for new, empty databases. I have also just sent a 'empty transactions' script to the guys which you may see in the download section in the next few days. You should only use it if you're familiar with PHP and MySQL - it's not really an end user tool.
osCommerce 3 is a major rewrite of the system, moving to an object-orientation. It's highly unlikely ANY code written for 2.2 will run for version 3 - the database structure and ways of accessing things like orders are very different.
I couldn't login to my account since I changed my company name. today I gain access to my frontaccount database, and find out all my records are gone! back to trial company records. I don't know if miss anything or is it not recommended to build records on top of the trial company?
I think what's happened here is that when you changed your company info, you ran 'Create/Update company' instead of 'Company Setup'. Doing this runs a database script against the tables, deleting previous info. It's easy to accidentally do, and yes, you have lost all your data unless you backed up first.
Suggestion 4 sounds like a good one to me too: make a default branch customer at the same time as the main customer. Thanks tclim I might try that adjustment.
Re the reports: I have used Jasper reports against the MySQL database. It's not really an end-user tool though, and you need to have a reasonable understanding of the database structure. On the other hand, you can have absolutely exactly what you want. Given reports don't change all the time, perhaps you could pay someone to develop those you need. Adding a reporting framework IMHO is not a high priority.
The PDF format is page-positional and not designed around dot matrix or line by line printers at all. I don't think there's much you can except print the reports as Excel documents, and manually format them that way.
mph in answer to your question: yes I have problems with Firefox too.
I think it might have something to do with your add-ons. I'm happy to just 'download' the file and click on it to see it, but if you really want to stay in Firefox, try removing any addons first to see if that fixes the problem.
Might be doing something wrong here.
I tried manually setting it, tabbing out etc.
It still defaults to 14 days from now, not the invoice date on the Invoice report.
I'm using:
After No. of Days 14 days
as the payment term. Is this correct?
When I check the debtor_trans table, there are two entries:
A type 10 with the incorrect due date AND
A type 13 with the correct due data.
I figure the invoice report picks up the type 10 info.
I only need to do this for a few invoices - is it OK to simply SQL 0_debtor_trans 'due date' field, or does the due date get used elsewhere in the system?
Tks
Pete
Hi Joe
Still here. Back in FA again, after using it non-stop of course!
I just sent you a version 2.33 updated Australian chart of accounts/Australian tax setup file.
I'll also send you a revised 'delete all transactions' script for 2.33 too. Strictly for the technical people, and useful for testing.
See you round here in the next few days...
Pete
I don't think leaping into FA is the right place to start. Get a book on basic accounting, and learn some concepts first. FA assumes you are familiar with accounting terminology, and it's easy to get yourself very mixed up if you're not sure of things. At the very very least, learn the double entry concept and A = L + OE.
That would be my advice anyway.
Hi fellas
Just wondering, can the due date be forced to be a certain date?
When I make a direct invoice, despite having a 'pay within 14 days' payment terms, and setting a historic date, it overrides to make the due date '14 days from now', not from the invoice issue date.
Is there a way to do this (I can't recall this happening in older versions?).
An alternative would be to set a global variable in config.sys where you could set a variabel to either 0 or 1. Can we maybe get some input regarding this from the community
/Joe
Just a thing to note: zero transactions and voided transactions are valid transactions, and are required to be listed from auditing perspective in places like Aus, and UK at least.
Zero transactions are often used at end of month to signify no activity, and voided transactions are of interest to forensic accountants! So, if there is a proposal to remove them from reports, it should remain a user/admin option. Overall, I wouldn't advocate it, but I can see how people might like the option with their systems.
Don't forget that you need to re-comment
$security_headings = array(
_("Inquiries"),
_("Accountant"),
_("System Administrator"),
);
$security_groups = array(
array(1,2),
array(1,2,3,4,5,6,7,8,9,10,11,12,13,14,16),
array(1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,20),
);
After your install, or you may see a blank screen when you login.
This is in the instructions somewhere, but had me stuck for a few minutes!
What does "I was unable to login " mean. Did you get a screen? Or does your login passwod fail to get you into the system?
You might try editing config.php and setting
$debug = 1; // show sql on database errors
$show_sql = 1; // show all sql queries in page footer for debugging purposes
$go_debug = 2; // set to 1 for basic debugging, or 2 to see also backtrace after failure.
$pdf_debug = 0; // display pdf source instead reports for debugging when $go_debug!=0
to see what's going on.
Hi Fellas, thanks for the latest version.
Can I just confirm this (in my own mind, and may help others too)? I've found the db upgrade instructions a bit unclear and had to 'relearn it' each version so wanted to clarify it. Is this right?
Upgrading Database
When?
- Done when shifting major/submajor version eg. 2.2.x to 2.3.x
How?
1. Copy your current config_db.php to the new upgraded source directory. This tells FA which db to use. This of course is the old version at the moment, and will require modifications to the structure of the database eg. keys, indexes and new/modified tables.
2. Go into Setup/Software Upgrade.
The system works out what you're old database version is, then lets you upgrade by clicking. The script knows what you're old database is called, and what it's prefix is eg. 0_ or 1_. It then applies the right .sql file via a php script from the ../sql directory eg. alter2.3.php.
If things go to plan, the upgrade occurs and you're back in!
Thanks Janusz.
Version was FA 2.1.5 I think.
Looking at my logs, I noticed httpd was crash-reporting every click. This was because of some dodgy PHP ini stuff I had for xdebug. When I take that out the screens are much faster - and the javascript can work as it's not waiting for things so much.
I'll let you know if this doesn't solve the problem.....
Thanks
Pete
Hi fellas
I've upgraded to 2.2.4, but am noticing significant slowdowns on all screens, and (I think as a result) javascript goes crazy (adds double lines, doesnt update etc. etc).
I'm not quite sure where to start looking, but do you have any tips before I do on profiling the code ie. should I set the debug settings on and are there logs to check?
Thanks
Pete
I noticed an option in the sales order report rep109.php to $print_as_quote.
When this is set to 1, the sales order document is meant to say 'QUOTE' or whatever you've got in your language, instead of 'SALES ORDER'.
Very useful, however there's a line of code that says
$print_as_quote = 0;
but when I changed it to 1, it did nothing.
Then I found out it doesn't work because the code picks up the option from
reporting/includes/reporting.inc
as PARAM_5.
I set that to '1' and the report now correctly says 'QUOTE'.
Question: is the $print_as_quote redundant in rep109.php? Maybe it's there as a declaration, not sure, but it would seem that PARAM_5 is the place to change it in
reporting.inc.
OK guys: here's a very basic Wiki entry for a random topic to give you a proof of concept flavour of how the online wiki might work. It's for the 'Search Template for Invoicing' page.
Steps:
1. Install the wiki module per instructions. You may have to change some permissions to keep things going (some of my directories/files were unwriteable after install)
2. Click on the Search Invoice Template page link (sales - Template for Invoicing)
3. In the wiki click on
(Create Help.SearchInvoiceTemplate)
Again, fix permissions if you have to.
4. Enter the following example text:
Purpose:
Often will you want to create similar invoices again and again. Rather than re-keying new invoices from scratch, Front Accounting lets you mark certain invoices as 'templates' and then use these templates to create new invoices with most of the information already filled in. This saves time by removing the need to re-enter all invoice information from scratch.
How to use:
Any invoice already marked as an invoice 'Template' will appear on this 'Search Template for Invoicing' page, based on the search criteria you enter at the top of the page. You can search on invoice number, location or item to find an invoice to copy. After clicking 'search' you'll see a matching list of invoices. From this list you can then choose the one you wish to copy and re-use by clicking the page-arrow image at the end of the row (next to the currency column). This will take you to the 'Sales Order Entry' screen where you can change the necessary details (customer, dates, items and delivery details) and create a new invoice by clicking the 'Place Invoice' button. To cancel, click the cancel invoice button, or return to the previous 'Search Template for Invoicing' screen by clicking 'back'.
Extra Notes:
Please note that you only can only template invoices that were originally marked as 'templated' when you created the original invoice. Unmarked invoices do not appear in the 'Search Template for Invoicing' page list.
------end of text------
Now you should have a working wiki page - get it again by clicking the Search Template Invoice link, and then the help question mark at the top right of the frame.
Note I didn't put in any formatting, and I'm not sure I got the functionality 100% right either, but it's more a proof of concept.
Let's have a discussion now about the general layout we'd like for each entry (it's so important to try to keep these consistent). For starters, I used 'Purpose', then 'How to use', then 'Extra notes'. Ideally EVERY SINGLE wiki page would follow a consistent format, as this is critical in imparting system knowledge to users. If we can agree on one, we can then publish this so people can stick to it. The alternative is to have a hotchpotch of layouts which would be pretty much useless for quick referencing on how to use the system. We also need some 'rules' on the articles. Here are some examples I thought of:
- no simply rehashing the field names (you know the sort of useless documentation I'm talking about: see just about anything in doxygen).
- good plain English or whatever language the wiki is in (native speakers can fix any contributions I'm sure)
- Always addresses the 'why am I on this page' through the purpose paragraph
- Doesn't rehash obvious, system consistent processes in detail ie. don't have to rehash how to fill in a search screen each time - this is consistent throughout FA.
OK - that's my thoughts - over to you. Feel free to change/tear apart - it's ok I can take it!
Cheers
Pete
As you may know SugarCRM has an extraordinarily complex database structure with meaningless keys, high levels of database normalisation and a very complex sales function and table structure. The systems are worlds apart in architecture and functionality : to be honest, I don't think the job is easily possible or commercially practical.
FrontAccounting forum → Posts by p2409
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.
