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 itronics
Well, it is always better to find exact reason of encountered problems than ommit it with workaround at random place where it first appeared, leaving the real solution for later. After testing both FA versions I can say this problem is absent in stable 2.3.24. I will investigate this issue further to fix the beta version.
NB The XOR usage in above code is rather standard - this is just simple test which is true if and only if 'active' flag changes.
Janusz
You need to define also two records under Item Tax Types for goods taxed with 8 and 18% VAT respectively. Also Tax Groups for your customer have to be configured correctly. More info you will find in Wiki.
Please describe exact scenario, where I can see this problem. I guess you mean the hook_invoke call in install_module.php file, but all seems to be right here.
Function check_table is used to check existence of table , or specific field in table, and works properly, but you are right - for purity the lines should be swapped.
The $hooks->deactivate_extension() is not being called anywhere in FA
Well, in your patch you have removed the line where the function was used indirectly by hook_invoke method (the method name was passed to be executed in this function) as callback to drop the spare tables. Could you explain what was the reason for this?
Janusz
I don't know. Maybe just changing the 'Bank Charge' input title to say 'Added Bank Charge' would be enough?
Janusz
This should be quite easy to understand: the option in company preferences is 'Legal text on invoice'. You know, legal text on invoice, and not on order, ok?
Janusz
This not a bug, just reality is different you think it is.
joe wrote:Because you did some transactions on the GL account before linking to the bank account.
Joe
So? This limitation makes absolutely no sense to me.
When you have any transaction entered in system which references to some existing entity in database (e.g. account) you cannot just delete the entity, because you will end with inconsistent database content. You will have transactions which references to nonexistent accounts. The account (even if is no more used) have to stay in database, but you can inactivate it, so it will not be used for new transactions.
Is that so hard to understand?
Your response to a possible bug is really strange and makes me feel a bit concerned about the health and future of this project.
You should not worry about the project health. If you need help you would make better sharing your questions without aggressive comments, which seems arise from your weak knowledge of widely accepted accounting system requirements.
Janusz
Prepayment terms are not available in Direct Invoice form. If they are on your setup, you have badly defined 'prepayment terms'.
If you want to issue invoice in prepayment mode, you need to entry Sales Order first, then entry received payment and issue invoice against the payment in 'Invoice Prepaid Orders' screen. Prepayment invoices are maintained in this special procedure, as what is invoiced here exactly, is payment received, not the goods sold.
Janusz
The legal text is printed in invoice footer, probably you have overlooked it.
Janusz
Cannot reproduce this issue. The units seems to be stored and retrieved properly.
Janusz
You are wrong. This is not security by obscurity, but exactly the same security class mechanism like used in other token based systems. You cannot access generated pdf file unless you know the exact report file name, which is long and randomly generated (not obscured!). If you think you know better way to provide pdf files, just write the code, pack and send to our contributions mailbox, then we will consider integrating your work into main FA code.
Regarding invoice number vs invoice reference thread, this is very interesting as example of local specifics, but I'm not sure the Bug reports forum is the best place to report this. I think it would be better to stick to terminology used in FrontAccounting instead, were internal unique transaction number is named Payment Number, Order Number or just Invoice Number in the case under consideration, and another arbitrary string assigned by FA user is name transaction (payment,order, invoice...) reference. I think it is counterproductive to force your point of view in this matter here, were exactly such terminology is used since the project beginning.
There are also good news in this matter: you can always make your own translation file (say de_LU.po) and name invoice reference as invoice number and vice versa, wherever you feel it is necessary 
.
Why not, good idea. The categories are set for 2.4 mantis branch. On 2.3 branch we will make severe bugs maintenance only, as the code slowly became obsolete.
Janusz
The code part you have removed is responsible for closing popup windows. In some browsers tabs are used instead of popups, but also in this case the tab should not be closed if it is the last one FA tab in the browser.
Which browers you have tried beside IE ?
Janusz
Sales Invoice is not for that !!
Can't you attach Customer Balance report to the invocie instead ???
If not, you will have to customize sales invoice report for your needs.
Janusz
I'm not sure I understand the problem.
In last step Credit Note value can be allocated to new invoice in last step via link on Credit Note row in 'Customer allocation Inquiry' (and not 'Customer Payment' ). And here all you can allocate is the Credit Note value, isn't it?
Janusz
Well, I'm not sure I understand you right, but for me the Bank Transfer screen is pretty intuitive.
When you withdraw cash from ATM, you don't always know the bank charge. It depends e.g. on the ATM operator, or whether the withdrawal request is stated in your bank account currency. Therefore the only amount you can register just after operation in FA is the amount received from ATM (say $100), bank charge will have to be entered later.
Another situation is if you prefer entry in FA your ATM operations later, when you receive bank statement. Maybe it is somewhat local specific, but in most cases you will see two numbers on related to ATM operation here: amount you received from ATM ($100), and amount the bank charged your account for the operation performed. You just have to enter those two numbers in the Bank transfer screen in FA.
In real life scenarios above you will never see the overall sum of withdrawed amount and bank charge you operate in the example (e.g. 10067.50), so it is no need to use it in FA Bank Transfer form. For me all here is rather simple and pretty intuitive.
Janusz
Regarding main question: yes, period closing is implemented in 2.4 beta.
how long do you think it'd take before FA 2.4 is ready to be used on production servers ?
It depends only on community response. Since beta release we have received no bug reports for 2.4 version so far. While I'm sure we have done all the best to make the 2.4 beta bugfree, I'm also pretty sure there are some bugs (we don't know about) in the release, just like in any other beta code. Therefore we have to consider 2.4 beta version as still untested, which means it is not ready to be used on production 
.
The only way to change this status is positive response from real FA 2.4 testers. In other worlds: you will have to test it on yourself, or wait until other user will do it 
.
Janusz
Maybe this specific browser version problem? Have you tried other browsers?
Janusz
We have to little info to solve on the issue. Is any error displayed, or just arabic texts are not printed ? Which fonts are you using?
Janusz
Yes, indeed, some cleanup here would make sense 
Janusz
I had problem with the Work order auto next reference.
What was the exact problem you tried to solve?
Janusz
Minimal requirements for MySQL and PHP are stated on System Diagnostics page (also at the start of install process), being 4.1 and 5.0.0 respectively. There is no 'recommended' versions, frankly I don't know how it could be defined .
Janusz
Yes, indeed, the problem exists. The regression was introduced with latest fixes before 2.3.23 release. I have just pushed fix to the problem into stable branch. The most easy fix for the issue is changing lines 47-49 to:
if (list_updated('role')) {
$Ajax->activate('_page_body');
}Until that changing security roles setup should be avoided. We plan to make bugfix FA release fixing the problem in next hours.
Janusz
As mentioned earlier in a couple of forum posts, we have planned to switch our main code repo server to Git distributed version control system for some time. While by last couple of years FA code was maintained in SourceForge mercurial repository, in our everyday development activity we entirely switched to git long time ago. This resulted in unexpected problems with sychronizing repo content from time to time, so finally we have decided officialy move our main repo under Git control.
From today FrontAccounting main code repository is available on SourceForge.net project site under url:
https:/sourceforge.net/p/frontaccounting/git/ci/master/tree/
For your convenience we also maintain official code repository mirror on Github:
https://github.com/FrontAccountingERP
Our older mirror at delta.frontaccounting.com stil remains active.
SourceForge Mercurial repository will be still available for archival purposes, but no further updates are planned here. If you are using Mercurial in your development, and do not want to switch to git DVCS, please consider using hg-git plugin for direct updates from our main Git repo.
Enyoj
Janusz
A word of explanation. The changes in interface proposed by Mithy are on early stage of development and will not go to just prepared FA in version 2.4. Anyway the proposed development directions are promising enough, so we will work together to integrate the code changes as part of next (say 3.0) version of FrontAccounting.
Moving menu scheme to database is right way to go. This approach gives maximum user interface design flexibility. I see no problem with implementing alternative menu layouts this way, giving ability to choose between current and arbitrary number of other menu layouts. The application performance should not suffer: the menu layout can be read form database once on user login and cached in session.
The proposed bootstrap theme is superious alternative for various mobile devices, but is not so good for standard PC screen/kbd interface. But don't worry, we do not plan to abandon support for current, more conservative themes.
Janusz
FrontAccounting forum → Posts by itronics
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.