This is fabulous!  Thank you so much for being so responsive to all of us crazy accountants!

2

(2 replies, posted in Banking and General Ledger)

Ah ... very good!  Efficient that those terms are used in a multitude of places.  In order to have the documents use words that are understandable by the general public (for invoices and purchase order and such) and have an abbreviated code for internal purposes would take much more coding for the program. 

It seems that us accountants spend a lot of time trying to make the outside world happy and satisfy our obsession with efficiency and logic.

I may still goof around and see what the effects are of tweaking those descriptions.

I know the end results would probably not be worth the amount of time it would take, but it would be nice if there was a table where the descriptions were saved with user editable data including a field for external documents and a field for internal reference.

We currently use OANDA for our exchange rates.  Can the source of the exchange rates in FA be changed to OANDA?

4

(2 replies, posted in Banking and General Ledger)

This is just a personal preference, but I thought I'd ask for those out there who might want a cleaner looking general ledger output ...

The transaction types show up as fairly long entries ... such as "Inventory Adjustment", "Supplier Invoice", "Journal Entry".  I don't see in any of the tables where that identifier can be modified.  It would be great if maybe another field could be added to the Forms Setup screen so that a shorter identifier could be set up.  I personally don't need to see the words "Journal Entry", I'd rather save some screen real estate and just see "JE" ... for Inventory Adjustment, I'd use "IA".  This way my general ledger entries wouldn't wrap to two lines and I could see more as well.

Is there anywhere that these descriptors can be changed currently as a work-around?

Thanks!

Some of the things us accountants would have in a Recurring Journal Entry could be handled via the Revenue / Cost Accrual option.  However, a Recurring Journal Entry would offer more flexibility and wouldn't post entries to future periods so far in advance.

The Revenue / Cost Accrual option can only debit one account and credit one account, this simplified one-to-one entry is not always the case.

If I was a programmer, this is what I would envision:

On the journal entry screen next to the Process Journal Entry button could be another button "Save Recurring Journal Entry". This would save the entry in an additional table (some reference ID would need to be saved with the line items so a recurring journal entry's pieces parts could be pulled up in the future).  Saving the Recurring Journal Entry wouldn't post the entry, the post would still happen as normal.

A new recurring journal entry table would mimick very closely the table that holds posted journal entries except for two additions ... a reference ID of some sort ... and a "date last posted" field.

A new transaction input form would be available on the General Ledger menu.  The screen could look just like the normal journal entry screen with the addition of a lookup for the saved Recurring Journal Entry.  The drop-down would show the reference ID / first so many characters of the memo field / date last posted.  You could change the amounts if necessary before posting.  When the recurring journal gets posted,  the "date last posted" field would be updated.  The date last posted should show somewhere on the screen (not editable by the user ... just so you know when it was posted last).

There would be three buttons at the bottom ... the normal Process Journal Entry button ... Save changes to Recurring Journal Entry button ... and one for Delete Recurring Journal Entry button.  The normal Process Journal Entry button would do exactly what it does to any normal journal entry ... posting the data to the general ledger.  The Save changes to Recurring Journal Entry button would update only the Recurring Journal Entry table lines for future entries.  The Delete Recurring Journal Entry button would remove the lines of the recurring journal only from the Recurring Journal Entry table.

I went to test the Revenue / Cost Accrual entry function and found a minor problem.  I set up my entry to start September 30th and accrue monthly for a year.  February caused the entry to post on March 2nd and on the 2nd of every month thereafter.  So February essentially got missed because the entries went ... December 30, January 30, March 2, April 2 ...

So I guess the rule would be if you want to do a monthly recurring posting through the Revenue / Cost Accrual function, you must date it any day of the month except the 29th, 30th, or 31st.

7

(3 replies, posted in Setup)

As an example ...

If I post a vendor's invoice on November 1st ... I publish my November financials ... then in December I determine the invoice was a mistake.  I void the invoice and indicate a date of December 15th, I would expect the entry to be reversed on December 15th.  Instead, the entry just disappears.

For audit trail purposes, even if the reversal is within the same month, the original entry shouldn't disappear, the original should show and the reversal should show.

Just my opinion from an accounting management point of view.

One more idea ... we accountants would like to accrue commissions based on invoice date, but the sales person probably doesn't have to be paid those commissions until the customer pays the invoice.

The salesman listing based on invoice date could be used for a commissions accrual entry and the salesman listing based on paid date could be used to set up the payable to the sales person.

In the sales person setup, I am assuming the provision percentage is used to calculate commissions. The salesman listing shows the results of the computation.

From a practical point of view, it would be great if there was an indicator on each line of the customer's order, check box (yes/no), to indicate whether the item is subject to the provision calculation.  It could default to yes and the order entry person could uncheck it.  There could also be a default indicator in the items table which carries over to the line in the customer's order.

This idea came from the fact that certain items billed to the customer (like expense reimbursements that aren't marked up to the customer and therefore no profit, possibly freight, possibly sales tax in the U.S.) do not generate commission to the sales person.

10

(5 replies, posted in Wish List)

It would be great to have three dimensions available instead of two ... we keep track of business units, departments, and individual projects.

Also, if parent heirarchy could be added to dimensions like GL Account Groups.  We have two main business units but within those business units we have three or more areas within those business units.  If I could set up those areas as having the parent of Business Unit "A" or Business Unit "B" it would give me more flexibility in running reports by the areas or general business units.

Beautiful!  I was reviewing that file but I guess I was just thinking too hard.  Max-width is so obvious.

Thanks so much!

I noticed when i run FrontAccounting through Firefox and I click on the combo box that contains the account number and name it shows the entire name while I am browsing down the list before I select.  So the view of the data actually is wider than the drop down box on the screen.

When I run FrontAccounting through IE, I only see the contents of the data in the width of the actual drop down box on the screen.

I love Firefox, but at work we are only allowed to run IE so I have to make sure I test the program on the accepted browser at work.

Is there an easy way to change the default width of all the occurrances of the drop down list that contains the account number and account name?

I was thinking it must be a global setting of some sort since the field is the same size wherever this occurs and no matter what theme I change to.  Since I am using the max account number characters, I don't get to see very much of my account name.  The other option could be to make the font size a little smaller everywhere so more fits into the same space but since I wear pretty thick glasses to begin with, I'd much rather have the field a little wider.

Thanks!

You'll want some sort of ID for each recurring journal so it's not just one big journal.  Most companies will have a recurring journal for Depreciation Expense, Amortization Expense, monthly expensing of annual insurance premiums etc...

Also, there are recurring journals where the amounts actually need to be changed ... more like a journal entry template.  I can imagine someone wanting to save the line items that make up their weekly payroll entry.  Each week, they can go in and pull up the entry and enter the appropriate amounts for the G/L accounts in the journal and post.  This would be a huge time saver!

It would be great to have an option to keep recurring journal entries in one "table" and be able to go in once a month, pull them up without having to re-enter everything, review them quickly and post them all.  The recurring journal entries get posted into the general ledger without the original pending batch being deleted ... it just sits and waits until next month when you want to go in and review and post again.

Since I was goofing around with a test company to see what I could accomplish, I did a little experiment by going in through PHPmyAdmin and took an existing account and changed the account reference right in the 0_chart_master table to 7000-COAD-CF-US and it was accepted into the table through the back door.  Obviously when I go back into the program and if I try to pull up that account to edit the GL account it errors and says it must be all numbers.  I was able to post an entry to it as 7000-COAD-CF-US and it looks just fine in the trial balance. 

I did have to tweak the column widths on the chart of accounts report to accommodate the length and width of the account "number".

So although technically from what I can tell there's nothing limiting the use of stuff other than numbers, there's no way for a user to actually enter a code like the ones I'd like to use.  I'll keep digging around, but if you could give me a hint as to the difficulty of removing that limitation from the programming, that would be awesome!

Thanks!

wink

I want to set up a test company to see if I can get the results I need for one of our foreign subsidiaries.  My big problem is the slicing and dicing we do to our financial data.  I need to be able to track jobs (use a dimension), track business units (using the other dimension) and we also track departments.

The bigger companies in our corporate "family" use Microsoft Dynamics SL (YUCK!) and we consolidate everything into Cognos.  Those bigger companies have a four digit account number and then a crazy subaccount number that includes the business units, departments, and even country/region (7000-COAD-CF-US).

I noticed the account field is varchar(15) ... if I could mix numbers and letters (and if I could use a couple dashes to make the account identifier easier to read that would be the best) I could easily set up a chart of accounts that would align with all the other bigger companies and make it easier to consolidate the data into Cognos with everyone else.

I thought that varchar was at least letters and numbers (not sure about special characters like dashes) but when I tried to use a couple different versions of my idea, the field kept saying only number data is allowed.

Is there any way to get around this restriction? I guess I could always create a mapping file in excel and convert the results before consolidating but it would be better for the end-users if they could easily see from the letters in the account "number" what dept and business unit they were selecting without having to do that mental conversion and potentially screwing up and posting something to the wrong account.  smile

18

(1 replies, posted in Setup)

Sales tax for Cuyahoga County in Ohio is 7.75% ... when I try to set it up it is rounding my rate to 7.8%.  Is there a way to change the field to accept and calculate using two decimal places?

19

(9 replies, posted in Banking and General Ledger)

OK so I'm feeling a little stupid now ... I didn't realize you could assign a bank account to a liability GL account.  This solves the whole credit card thing.  Create the GL liability account for the credit card, create the "bank account" to link to the liability account... enter your supplier things ... "pay" them using the "bank account" which is actually the credit card.  And then as Joe said do a bank transfer to pay the credit card.  It's genius!!!  I ran through some sample entries in the demo and it worked fine.  And the beauty is that the bank reconciliation should work for the credit card statement just like the bank statements too!!!

The more I experiment with this program the more I like it!!!

20

(9 replies, posted in Banking and General Ledger)

The only problem with this technique is you end up with "bank accounts" that have negative balances since credit cards are a liability not an asset.

You could set up a vendor for your credit card.  Whenever you use your credit card to charge an expense, you enter an invoice to your credit card vendor and use the memo field to identify who the charge was made with.  When you make the payment to the credit card vendor, you can select the individual charges to apply your payment to.  In this way, you are actually reconciling your credit card statements as well.

I guess this technique would work best with expense items and not inventory items, but I thought I would throw this idea out there.  Maybe it could be helpful to some.

Although it seems like a minor temporary entry, it is critical for the proper balance of assets on a company's books when the received items are inventory.  It is not uncommon for items to be received before the end of a month and the vendor doesn't get the invoice out until the beginning of the next month.

I hate to mention those icky big box accounting packages, but I've had experience with both MAS90 and Microsoft Dynamics SL (which I hate with a passion), and they both have a "secondary payable" account commonly called PURCHASES CLEARING that is used for the credit side of the purchase receipt that is then debited when the invoice is received.

We have lots of issues with timing and inventory is a critical part of our business so this process would be critical.