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 oakstreet1
This may be in the Wiki, but I don't remember seeing it, and it took me a while to figure out how to deactivate a user.
In the user accounts function (under Setup), you must check the "show also inactive" checkbox to see the checkbox that lets you disable/deactivate a user.
Once you click "show also inactive", the "Inactive" column appears and you can check the checkbox there to deactivate the respective user. You don't need to save anything after you check the box. That's it.
I was actually studying includes/db/audit_trail_db.inc. When no audit records match with GL transactions, it looks like it issues a warning like: "Some transactions journal GL postings were not indexed due to lack of audit trail record". That led me to believe that all gl_trans records are expected to have a matching audit record.
When to write an audit record is causing me some confusion.
I probably did something to cause this. When I started entering things in January, I was doing everything wrong, and I had to restore from backups more than once.
In reading the audit_trail PHP script, it appears that it would be an error for there to be any gl_trans records with non-zero amounts that don't have a corresponding audit_trail record. Running reports manually in MySQL, I find 4 gl_trans records that do not have a matching audit_trail record.
The first two are type=0; the credit/debit for the opening balance of a bank account (I just put the opening balance in as a deposit on January 1, rather than putting it in for the previous fiscal year, then closing that fiscal year ... I didn't know how to do that, back then).
The next two appear to be from a line item on an invoice (type=10).
Do I need to fix something, or is this just going to post an informational message when I close this fiscal year? All of the general ledger entries are correct and everything balances.
+---------+------+---------+------------+---------+-----------------+----------+--------------+---------------+----------------+-----------+
| counter | type | type_no | tran_date | account | memo_ | amount | dimension_id | dimension2_id | person_type_id | person_id |
+---------+------+---------+------------+---------+-----------------+----------+--------------+---------------+----------------+-----------+
| 32 | 0 | 3 | 2018-01-01 | 1060 | Opening balance | 4495.54 | 0 | 0 | NULL | NULL |
| 33 | 0 | 3 | 2018-01-01 | 3590 | Opening balance | -4495.54 | 0 | 0 | NULL | NULL |
| 46 | 10 | 7 | 2018-01-09 | 4012 | | -48 | 0 | 0 | NULL | NULL |
| 47 | 10 | 7 | 2018-01-09 | 1200 | | 48 | 0 | 0 | 2 | 3 |
+---------+------+---------+------------+---------+-----------------+----------+--------------+---------------+----------------+-----------+I realized, after testing on my client's server (also CentOS 7), that I had compiled my own PHP module for another issue I had, and I had not compiled in zlib support, so I recompiled and everything is working. Sorry for wasting your time with that.
Thanks. I'm not sure I'm ready to downgrade MySQL, as I'm using it for several projects. The server I'm going to install this on for my client is running server version: 5.5.56-MariaDB.
I am using my installation for my business (so I can learn FrontAccounting and do real-world testing), and so far everything has been working for me ... except the install/activate extensions stuff, which I am not sure I need for my small software development/consulting business.
I'm using a CentOS7 server with PHP 5.6.23 and MySQL version 5.7.15.
I think I'm missing zLib because I don't get any installed/available extensions, languages, etc. on the setup page. I haven't figured out how to add zLib to PHP using Yum. I'm not in a hurry to compile a custom version of PHP because I prefer to use Yum to keep the system updated.
Ok. Thanks. I'm not sure how the language translation would work with the installed_languages.inc file pointing to a non-existent folder. The error log was getting appended constantly. I just installed the en_US.po file you linked. I still have a month to get all of this working correctly. I am making progress, but I still have more questions.
Apparently my installation got messed up a bit by this. I discovered that the default language in lang/installed_languages.inc was "C", but the lang folder didn't have a "C" folder, but rather an "en_US" folder. I edited the installed_languages.inc file to use 'en_US', but I still had a problem, because the file in lang/en_US/LC_MESSAGES was named "en_US.mo", rather than "en_US.po". After renaming it, the errors stopped.
That is now fixed, but that's not the problem I had set out to find. 
This is useful. I will be writing the customer migration code, soon. Thank you.
Yes, I was referring to sql_functions.inc. The commit_transaction() could cause the transaction level to go negative, which would nullify all following transactions. I was just thinking that commit transaction should test transaction level for > 0 before decrementing the value.
I'm just familiarizing myself with the code before I get started on a rather major extension ...
In /includes/db/sql_functions.inc, there is a function called "cancel_transaction". I'm not sure if or when that is called, but if it were called inside of nested calls to begin/commit transaction calls and any function called "commit", the global $transaction_level would go to -1, which would cause all following begin/commit calls to be ignored.
I could be missing something, and maybe the cancel is never called, but I can imagine some additional checks to be sure that $transaction_level never goes negative. I'm not here to criticize something I don't completely understand. I just thought someone might want to consider this as a source of some unpredictable behavior, as, once the global was out of range, all subsequent "transactions" would actually not be done as transactions.
An extension may do the job, but I'm not sure you want to manage your memberships in your accounting software. I do something like this for a client with 65,000 members, and we keep a separate database for managing member information and interactions. We use a common account code to link the membership data with the accounting system, which keeps the accounting system isolated from many user errors. We can also allow users to manage their own record through a web interface, without letting them near the financial data.
FrontAccounting seems to have CRM features that may make it suitable for this, but I'm thinking you'll want to keep track of more information about your memberships.
That wiki could use an update, because there is now a BCC address in the company setup.
I'm not sure if this is any help, but it will move the amount from an account receivable to a bank account, so your assets would stay the same and it has no effect on revenue, because the sale was recorded when the invoice was created.
I ran into a snag when I inserted a fiscal year with a lower ID, because I inserted it with closed=0 (not closed). The UI would not allow me to enter any transactions so I hunted through the code and discovered that I needed to re-open that fiscal year, so I switched the company's fiscal_year back to the current year, logged out, changed the previous fiscal year to closed (in mysql), logged back in, opened the fiscal year in FA, re-selected that fiscal year in the settings, and I was able to enter transactions. (this is all in the Test Company, for now).
(I haven't quite deciphered the audit_trail/GL checks that determine when a fiscal_year is open.)
I was then able to enter a credit memo, switch to the current fiscal year, and see the correct opening balance.
Thanks again!
Thanks. That is good information. I'll definitely be sure to create the necessary fiscal years in the right sequence when I do the actual migration!
You are very helpful. I will be sure to make a donation towards FA as I will probably have a lot of questions, and I really appreciate the effort that goes into developing a complete accounting system. I also like the way the FA code is organized. You guys do good work.
Thank you. I didn't think I could issue a credit without an invoice, but I see that I can.
I'm testing with the Test Company and I've entered a lot of stuff to analyze the transactions. Can I create an earlier fiscal year to test this, or do I need to start fresh/clean company and create the fiscal years in order? Somewhere I saw someone say that the fiscal years had to be numbered with the earlier years having lower ID numbers.
I think I've read everything in the Wiki about setting opening balances, and I get that I would need an invoice to create a normal balance on a customer/debtor (AR) account.
However, the company I'm working with is set up such that most of their customers have credit balances. I know I can create an invoice and then overpay that invoice to create a credit balance, but that seems like a lot of extra stuff just to set an opening balance on a customer (debtor) account.
Suggestions?
Background: I'm a software developer with 10+ years of PHP and 25+ years of database experience. I am coding the conversion from the client's old system (non-SQL) to FrontAccounting, so I don't need the UI to do this. I just want to do it the right way. I am using the UI and database diffs to analyze how FA stores things.
Is there a reason you couldn't just transfer money from petty cash to the bank account, in this case?
FrontAccounting forum → Posts by oakstreet1
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.