1

(1 replies, posted in Report Bugs here)

Hello FA community.  I'm a huge fan of Front Accounting.

I'm not certain where the best place to post this issue is, but I think "bug" section might be a good place to start. 

I had a journal entry which was erroneously reversed.  Rather than debiting say COGS for $1,815.49 and Crediting Inventory for $1,815.49 I reversed this, erroneously debiting the inventory account and crediting the COGS account.

I noticed the error almost at once and went about to correct it.  I naturally thought I would have to post a correcting JE for $3,630.98. Then I had a thought.  I wonder if FA will just allow me to just correct the entry? 

Sure enough, it did.  Not only did it allow me to correct it, it wiped out the previous entry entirely. As we all know, accounting should show every transaction, and not allow corrections of this nature to occur, especially without an audit trail. 

I know a ROLE change could prevent this entirely by just disallowing the user make a journal entry, but we certainly have roles that allow in-house accountants to make a JE change.  This "re-write of a JE without an audit trail" is a huge NO NO. 

I went back to look at the "Audit Trail" report, and it just shows the corrected entry.  So I have to say this isn't an accurate audit trail. An accurate audit trail would show the original journal entry (the wrong one) and then show it was corrected. 

What am I missing here?

Thank you for your thoughtful responses.

lomash_sht wrote:

I have been using this software for more than a year. However, there is a substantial flaw in design of the Inventory Movements. The software uses average cost method, but, there is standard cost method to transfer the cost of inventory sold to Cost of Goods Sold GL. This standard cost is ever fluctuating and often negative. How is this possible if costing method is average cost method is used? The software is a headache when there is high volume stock in and out. Especially when goods are returned, the cost of the returned goods is automatic and I dont know how the cost is calculated.

Secondly, the standard cost is frequently negative and the auto cost update is a headache because of lack of trail. Why the inventory valuation rate is different than standard cost? Is standard cost calculated based on average cost? If yes then when the standard cost is manually updated, should not it affect the inventory valuation?

Can someone explain in detail how the inventory costing can managed and how to stop cost update.

P.S. accounting norms does not allow cost updates. Can this be made optional in system settings ?


Did you ever get an answer concerning this?

STANDARD COST. 

When our client purchases an item, or several items, for sale, the price of the item is routinely ignored and the "standard cost" is used in the instead.  Inaccurate averages entered into the books of account is contrary to generally accepted accounting principles.  I am at a loss to understand why this method is being observed in FA.  The true "average costs" in this particular case are approximately $6.50 ea.  The Standard "calculated" Cost is $3.49, and the  $3.49 calculated average cost was used to debit COGS and credit Inventory.  This is a VERY SIGNIFICANT flaw and the system would not pass Audit.  What can be done about it?

I went back into the system to see what was going on.  I noticed that the AVERAGE PRICE had been re-calculated to something that was closer to actual prices. The problem is the POSTED GL ACCOUNTS still reflected the eroneous $3.49 cost.  MAJOR ERROR. HAS TO BE FIXED.

I would be interested in funding some development of this module.  If we could get a dozen people to participate I'm sure we could fund it.  The module could then be offered to users for a fee which would allow us to recoup our investment.  Without a robust and "working" import transactions module, I see FA becoming less and less relevant.  Which would be a shame since the 'bones' of the app are excellent.

Gerizineink wrote:
lp wrote:

I recently saw a post on twitter (see below) regarding a developer that was setting ISO 20022 compliant payment processing system for XRP / XRPL.

I'm thinking this sort of payment arrangement is the way of the future and would allow convenient banking access to anyone using FrontAccounting.

In short, this guy has setup some software (on Github) that will process multi-payments (via the XRPL - possible in various currencies however transferred in XRP) via an exported csv file from an accounting system. Likewise, the software will allow for the download of transactions from an XRP account and export into a csv file for import/processing into the accounting system. This is to be done in the upcoming compliant format per ISO 20022. 

Just wanted to put it out there and see if anyone else has some thoughts on creating import/export csv's for FrontAccounting, that would allow convenient processing of payments and receipts via XRP/XRPL in a compliant upcoming banking format i.e. ISO 20022.

https://twitter.com/SchlaubiD/status/1536282159601926148?s=20&t=s3wKS9nSjm5-hg_UTILheg
https://youtu.be/-u307nu72SQ
https://t.co/OGZajUPYML
https://t.co/uq7XP8rraw

Cheers

Thanks for the interesting idea!
I have familiarized myself with the materials you provided. I personally prefer the usdt payment method - it is an interesting option for processing payments, but in this case I see the advantages of using XRP/XRPL.
Creating CSV files to import/export to FrontAccounting using XRP/XRPL is a promising idea that could:
Simplify payment and receipt processing.
Provide access to banking transactions for FrontAccounting users.
Comply with ISO 20022, which will become mandatory for bank transfers in Europe.
I will be glad to follow the development of the project and share my thoughts.

P.S. I also read the other materials you provided and found them very informative.

5

(26 replies, posted in Modules/Add-on's)

Well somebody needs to do something. Perhaps a few of us need to hire a programmer and then just sell the solution until we break even. This issue has been going on for years. 

trafficpest wrote:

We should make a plaid banking plugin. I was thinking and looking into it but didn't feel like doing the work lol!

6

(26 replies, posted in Modules/Add-on's)

Exactly what happened to me.  I brought it up.  Crickets.  Ever figure it out?

I followed the import transactions 'help' closely, and even downloaded the sample csv for journal entries.  I changed the date, and the account codes.  I process the file and it appears on my screen properly.  However when I check, nothing has been posted.  Any ideas what I might be doing wrong?

8

(2 replies, posted in Fixed Assets)

Thanks KV

9

(10 replies, posted in FA Modifications)

It's not a problem.  Once I create a new company, and then run a mysql script that updates gl_classes, gl_coa, quick_entries, fiscal years and other things.  Take less than 5 seconds.  ;-)

rafat wrote:

I think @joe was very clear with this and I quote him:

joe wrote:

Hello Sir,

I guess you are referring to an external COA. In the FA core there are 2 COAs, en_US_demo.sql and en_US_new.sql. These 2 COAs only contains two fiscal years, Currently these are 2020 and 2021.

In the next minor release these will be updated to 2021 and 2022.

All the COAs in the Extension repository are maintained by various users and some are probably not updated.

Joe

You get an answer to this?  It's pretty easy, but don't want to answer if you already have your answer.  Confusing.

11

(2 replies, posted in Fixed Assets)

If I have 100 Fixed Assets, someone please tell me I don't have to hit "process depreciation' 100 times.  Where's the batch option? Thanks.

12

(10 replies, posted in FA Modifications)

I think I was referring to something else. 

My new company installations still default to 2017/2018.  This is a brand new company setup (today 02132023), and clearly it doesn't really likes 2017/18.  Must have been a great year!  ;-)  - - Not sure it matter but I got this after selecting 5-digit coa.


rafat wrote:

what did you find and how you solved it?

gotcha.  Thanks.

thanks for this, but I'm not seeing any archived messages.

joe wrote:

After some initial statical problems while converting to Archives, it seems to work now.

Joe

If they aren't visible in the GL, then I doubt if they're in the proper table.  It's just a read after all (select * from XX where YY = ZZ;) 

aletheamartinez wrote:

I downloaded the frontaccounting-2.4.8.zip,

Enabled this function, enabled for the user. Inserted around 300 COA records in Chart table using mysql- phpmyadmin tool. I am able to see COA in Journal Entry screen. This is good.

INSERT INTO `0_chart_master` VALUES                                                                 
('1010000', '', 'CASH - BOK FINANCIAL          ', '1', '0'),                                       
('1011000', '', 'CASH - AZ BIZ BANK - MM       ', '1', '0'),                                       
('1015000', '', 'CASH - PACIFIC PREMIER        ', '1', '0'),                                       
('1020000', '', 'CASH - DEPOSIT ACCOUNT        ', '1', '0'),                                       
('1021000', '', 'CASH - DEPOSIT IN TRANSIT     ', '1', '0')....................

Created the following csv format for journal entries,
entryid,date,reference,accountcode,dimension1,dimension2,amount,memo                               
000001,07/15/2020,JV000001,2000000,,,-15970.00,"0000000033 I VEND L21140 "                 
000001,07/15/2020,JV000001,8550010,,, 15970.00,"0000000033 I VEND L21140 "                 
000002,07/09/2020,JV000002,2000000,,,-06305.00,"0000000393 I VEND A19250 "                 
000002,07/09/2020,JV000002,8600000,,, 06305.00,"0000000393 I VEND A19250 "                 
000003,07/04/2020,JV000003,2000000,,,-01900.00,"0000000526 I VEND K05225 "                 
000003,07/04/2020,JV000003,8660000,,, 01900.00,"0000000526 I VEND K05225 "                 
000004,07/10/2020,JV000004,2000000,,,-01550.00,"0000000527 I VEND K05225 "                 
000004,07/10/2020,JV000004,8660000,,, 01550.00,"0000000527 I VEND K05225 "

It is not showing any errors or message and the records are not posted in Ledger accounts.

Please help on this.

Thanks

16

(6 replies, posted in Wish List)

I don't think you need a separate one.  Just a chunk of this one designated for older threads.  Some good info in there.

Hi Bruce,

I'm a CPA licensed to practice in North Carolina.  I have used FA for some time.  It is, as you know, extremely powerful, but it's easy to get it off track if one isn't careful.   If you care to drill down a bit for me concerning the issue(s), I can noodle it better.  For starters, where are you seeing the allocated balances?  On a Financial Statement, Trial Balance, or a General Ledger Report?  Are you pretty familiar with mysql?  Ever get in there and perform queries? Do you have multi-fiscal year editing turned on?  Do you see the same bank reconciliation error every month?, or different ones? 

MacKenzie

18

(4 replies, posted in Dimensions)

I look at dimensions like almost a non-accounting function.  We used to keep books for a lobbying concerning.  We tracked typical stuff like travel expenses, meals and entertainment, and that was fine, but at year end they also wanted to know, ok, out of all these expenses for all these projects, how much was spent on Red-Dye#2 (Grocery lobbying).  That what I would use it for. 

advocaat.pollet wrote:

Deliveries don't have GL-bookings and the intention is to batch deliveries in an invoice, but only select the deliveries of a dimension.

F.

Were you able to get this resolved?  I think it happened to me once.

cedricktshiyoyo wrote:

Dear @joe I just installed new FA on Ubuntu 20.4 with PHP 7.43 MYSQL 8

After registering assets in the system, i am not able to find them again, to modify or delete them,
supposed to be under maintenance fixed Asset tab, but it only showing 2 tabs, general settings and transactions. there is no where to select existing assets to either modify the description, code or depreciation date.

thanks

I'm happy to report that I was able to get this working.  I still have NO IDEA why it abended before. 

itronics wrote:

Thanks for your comments.

Regarding the fonts used in FA I have to agree.  The themes for FrontAccounting were designed long time ago, for much lower resolution displays than current FHD standard. We will fix this soon. (In before, the application is designed for table displays, not smartphones, so - even if we received some suggestion to change this - we will stay with assuming table monitor as target display).

Regarding Hrm module by Nostrinos, I have just updated the version available from default FA extensions repo. Please test if you have any problems with this version. Frankly, in now way I could reproduce your problems with the module. Both previous as current version installed on fresh new FA installation works as expected. Yes, I could point many constrains in usage of this module in real business workflow, but bottom line is it just works. For any feature improvement please contact HRM module author.

J.

21

(6 replies, posted in Wish List)

I agree with Rafat, who agees with poncho1234.  It's crazy that new users can't attach a picture to their posts.  Also, as I pointed out before, seeing posts 10 years old in the 'active' forum makes zero sense.  I realize there is some utility in these, but move them into an historical archive directory.

It's a bad look for new users.  We're trying to grow FA, right?

Accountants, at least here in the United States, are taught to never purge records.  If you disagree with this then have at it.  But if you agree it's a good idea to keep them (audit trail purchases), then you're left with AJE's.  Adjusting Journal Entries.  That's what I would do personally.  Good luck.

brucek@pelhamhs.org wrote:

I have been using FA for about 10 years now.  As I have upgraded, learned what the hell I was doing, changed my procedures, and generally used the system, there has been a slow accumulation of errors that I would like to somehow purge. 

Off the top of my head:
- Unallocated payments
- unreconciled bank transactions
- default bank reconciling starting balances

I have items that are up to 10 years old that still show up (but are locked because the years are long closed) that I would like to make go away.
Any ideas?
Thanks

OK, if it's needed by the "gumment", but on the Purchases tab it has a "Purchase Discount Account".   This won't work?? 

Accounts Payable Account:   
21010001    Accounts Payable
Purchase Account:   
Use Item Inventory/COGS Account
Purchase Discount Account:   

seahawk wrote:

In RSA you have to declare Discounts received from a supplier and discounts Given to Clients.

24

(5 replies, posted in Setup)

I think that will work.  Personally, I would probably just mysql -u root - p, and insert the records in a new table.  :-)

mawulitse wrote:

I was missing two tables, and found them based on this thread:
https://frontaccounting.com/punbb/viewtopic.php?id=7241

Below are the steps for anyone with basic knowledge like me.

1. Using phpMyAdmin or similar tool, identify the company prefixes. In this example I want to transfer the data from Company 0 to Company 1.

2. Using the RENAME feature under Operations, move the following tables to different names (delete might work but something could go wrong)
    1_crm_contacts     --> x1_crm_contacts
    1_crm_persons      --> x1_crm_persons
    1_cust_branch       --> x1_cust_branch
    1_debtors_master  --> x1_debtors_master
    1_suppliers            --> x1_suppliers   

3. Use the COPY feature under Operations to bring the data from the original company to the new company:
    0_crm_contacts     --> 1_crm_contacts
    0_crm_persons      --> 1_crm_persons 
    0_cust_branch       --> 1_cust_branch
    0_debtors_master  --> 1_debtors_master
    0_suppliers            --> 1_suppliers

That's it. Company 1 should now have all the contacts from Company 0.

25

(10 replies, posted in FA Modifications)

**************************
I found this.  SOLVED!
**************************