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 ITCynic
Pages 1
Hey Pete.
Thanks for all that research you have done. Most impressed 
For now I have done what Joe has suggested, namely clearing the cache browser. That makes it seem to work.
In retrospect, I should have considered the browser cache as I have seen this cause strange behavior elsewhere, especially when creating websites in Drupal.
Regards
/Andre
Hey Joe,
Thanks for persevering with this issue. See ..... you are passionate about FA
I cleared the browser cache and date picker works fine now.
Regards
/Andre
otherwise make an offer to pay someone to sort out the problem for you rather than criticise the developers because they don't do it your way
Thanks for your insight, I actually did offer to pay for an amended purchase order layout and unfortunately both developers are "too busy". In any event, I am busy reviewing the code to see how to do the mods myself.
As per your suggestion, I will try a different java date picker, thanks for that tip.
Hi Joe
No difference in behavior, still incorrect. Using FireFox 3.0.11
http://zjunction.com/datefunc2.exe
/Andre
Hi Joe
Your solution is only partly working as is.
It was not my intention to provide a piece of working code, I cobbled that together in a few seconds to explain the concept of what I would have done if I were writing in Clipper. Besides I have not coded for at least 15 years now.
I think our algorithms are quite ok.
My post was/is not a comment on your coding styles or algorithms. In fact I have repeatedly stated on this forum that you guys have a brilliant application and commended you for the good work so far.
It is when calling the JavaScript routines that things get screwed up when using the / as separator in the English - South Africa environment
When I evaluated FA in v2.03 I am sure this was not an issue.
Off topic :-
From both your and Janusz's reply's to various user posts, I get the impression that you are both :-
a) extremely passionate about FA
b) always too busy to provide detailed help / how to's
c) seem sensitive when someone points out a deficiency or bug in the application and you would rather have a finger pointed elsewhere.
I do understand that FA does not pay your bills and is a labour of love with development being done when resources permit and I commend you and Janusz on your incredible efforts. For a 2 man team to get this much accomplished is pretty impressive.
I was under the impression this forum was about users communicating with the developers (yourselves) to assist in creating the best Open Source accounting package there is.
But I keep reading questions of a similar type being asked and not being addressed because it "will be considered in the next version" or "will be addressed in the next version" or "we are too busy with the next version".
I think the users of FA and fellow forumites should ask themselves the following questions.
"I prefer constant development to the next version with new features." or
"I prefer a freeze on new features with more bugs being ironed out of current versions."
Personally, I prefer a freeze on new features until bugs are ironed out in current versions.
I have been following the progress of FA for the past 11 months, hoping it will get to a point where I can start recommending it to clients but all that is happening is new feature requests rather than making existing features stable, rock solid and bullet-proof.
Maybe, what I am looking for (a stable, customizable application actively supported by the community) is not really on offer here yet.
Please view these comments from someone who really wants to use and promote this application (like other forumites) and see it become the best Open Source accounting package there is.
Regards
/Andre
It seems to be in the operating system.
I very much doubt it is the operating system as this would have quite a impact on many applications that use dates. (remember the Y2K debacle?).
In my days as a Clipper programmer I would have checked the the date format type ( ie American or British )
and then evaluated the date entry field to pass the correct date format to the calendar function.
If the date is British and the calendar function is American I would rearrange the date string in the correct order before calling the calendar function,
For example
If date = "British"
dDay = DAY( dDate)
dMonth = MONTH( dDate )
dyear = YEAR( dYear )
dResult = GetCalendar( dMonth + "/" + dDay + "/" + dYear + "/" )
dDate = DAY( dResult) + "/" + MONTH( dResult) + "/" + YEAR(dResult) // Would return dDate in British format
else
dResult = GetCalendar( dDate)
dDate = MONTH( dResult) + "/" + DAY( dResult) + "/" + YEAR(dResult) // Would return dDate in American format
endifNot being a PHP coder I am not sure how one would do this, but I am in the process of trying to teach myself PHP so I can modify your forms layouts.
Regards
/Andre
Yes I see that your example is doing something wrong. Maybe there is a javascript problem on your client. This is the first time I have heard of this.
And I still can't reproduce it.
Did you try to logout and login again to see if it helps?/Joe
I am using Java 6 update 13 - all my other java stuff works fine. Other demos elsewhere using similar techniques work fine. I doubt it would be the java.
My regional settings in XP is "English - South Africa" . Try setting your region to mine, also my short date in XP is "dd/MM/yyyy" and the long date is "dd MM yyyy"
Logged in and out a few times.
The tool I used is Screen2EXE found at http://www.screen-record.com/screen2exe.htm
/Andre
I have placed a self running (EXE) video to demonstrate this. Download or run from the site. Your choice.
http://zjunction.com/datefunc.exe
/Andre
Almost always a supplier will have their own item codes, and an item description. Our Item Name, would be very similar if not the same as supplier description,
Item codes sometimes get complicated and are difficult to read without Item Name showing in lists and reports.
Alvin
I agree with Alvin.
The big issue here in South Africa is that the standard of expertise and educational level is very low with most general employees. Some have not even finished high school and only have basic reading & writing skills.
We do not have the best education system in the world so we have to make allowances for that. In the bad old days of apartheid, non-white people did not have access to decent education at all and now with our present government policy of affirmative action (racial quotas), by law we are forced to employ these people, no matter how lacking in skills.
Please do not view this post as political, merely a statement of a distressing fact.
So having the description displayed would assist. Possibly the developers could advise where to add the bit of code and we can then do it ourselves.
/Andre
When the date format is chosen as "DDMMYYYY" in display setup the date_picker function does not work correctly.
It appears dates are only passed to the function as "MMDDYYYY"
ie. with the date entry fields as 06-12-2009 (12 June 2009) with date format "MMDDYYY" the date_picker function opens to 12 June 2009 as expected.
with the date entry fields as 12-06-2009 (12 June 2009) with date format "DDMMYYYY" the date_picker function opens to 6 December 2009
/Andre
Hi Janusz
Thanks for the reply. Much appreciated!
I enabled 'Search Item List' as suggested, while using your on-line demo, and it works perfectly as anticipated.
Fantastic ! Thanks for pointing that feature out to me.
I fully understand that you & Joe have done an exceptional job with limited resources and I look forward to further revisions as each revision just seems to get better and better !
I feel this issue is not really a bug, more an anomaly and you have shown me a work-around so I can continue evaluating this great package.
However, it would be nice if you would consider a solution for inclusion in future revisions/releases, maybe blocking the item code field from entry unless the "Search Item List" is enabled.
Keep up the good work !
Regards
/Andre
Hi Janusz
I am really not understanding your reply. Somehow I think you are agreeing with me that prices are updating correctly but I am not experiencing this.
Please be so kind to look at the following screenshots if you dont mind.
http://zjunction.com/screenshot.61.jpeg
- In this I have selected items with the list selector under "Item Description" and items are populated with the correct selling prices as they should be.
http://zjunction.com/screenshot.60.jpeg
- In this I have entered the item directly into the "Item Code field" and then pressed the "Add Item" button, without overwriting any other fields displayed.
In each instance the price displayed is the price from the first item in the list selector and not the price of the actual item selected. It is as if the correct price has not been read from the database for the item entered.
Are you are saying this behaviour is correct ?
At present I have +/- 12,000 items in my current application and whether I enter the item codes directly or use a list selector, the correct price is always shown. In your application this is not so.
Would other forumites following this post please have a look at the screenshots as well and their comments would be welcome.
I am not sure over your statements in the last paragraph so lets ignore that for the time being. 
Regards
/Andre
Hi Joe
I appears that quite a few posts in the forum seems to ask about changing document layout.
Perhaps a How-to/Example on how to change layouts could be useful ?
/Andre
Hi Janusz
I am not sure whether it is a loss of focus as ANY item code entered in the "Item Code" field does not update the selling price.
As your post refers "experienced users (those knowing the item codes) prefer to use keyboard" I assume that all fields should update to the correct information. i.e. correct selling prices etc
All that updates is the item description. Check the on-line demo to see what I mean.
I love your comment "random bad people" .................... Here in South Africa they are not so random.
/Andre
Hi everyone,
I have started to test/evaluate the latest version of FA and I must compliment the incredible work the developers are doing for this application.
I have noticed an anomaly that could create issues when selecting items for invoicing :-
This is what I discovered when doing a Direct Invoice in the demo.
When one selects an item (Item Description) from the drop down list the "Price" field is correctly populated with the price of that item.
If one chooses to enter the item code instead, the "Price" field is not updated and a strange behaviour is noticed.
For example :-
In the demo choose "Direct Invoice"
1. Under item description choose "102 - 17" VGA Monitor" and take note of the price (10.00)
2. Now, on the same line item, enter "104" in the item code which should populate the item description with the product.
You will notice the selling price remains at 10.00 which is the price of item code "102"
3. On the same line, choose "104 -52x CD Drive" from the item decription drop down.
The selling price remains at 10.00 ie the correct info is not being passed for that code (104)
4. On the same line under item description choose "102 - 17" VGA Monitor" and take note of the price (10.00)
5. On the same line under item description choose "104 - 52x CD Drive" and take note of the price (34.00)
6. on the same line item, enter "102" in the item code which should populate the item description with the product.
You will notice the selling price remains at 34.00 which is the price for item code 104
We know the price of item "102" is 10.00 but the selling price is that of item "104" 34.00
So in essence if we have a user who enters a low value item via the item description the item will be displayed correctly. Now the user enters a code for a low value item in the "Item Code" field the description will be correct but the selling price will reflect the price from the previous low value item. This will allow the user to create an invoice with the correct line item description but the wrong selling price.
Users over time start remembering codes so this leaves the application vunerable for abuse.VERY DANGEROUS!
Somewhere on your code something is not updating.
Also maybe there should be a setting to prevent an item being sold below cost on a per-item basis.
I hope I have been able to explain this anomaly properly for the developers to replicate.
Regards
/Andre
1. I have found that I require additional fields for the supplier entry page and I am confident that others could/would find them helpful as well if they were included. This extra info would be mainly for appearing on purchase orders etc.
As I do not know how to post images to this forum, I have created a mockup which can be viewed at http://zjunction.com/Suppliers.htm
I have displayed the additional fields required in red.
2. Also, the field for 'Bank Account', I am not sure what the intention of this field is. Normally, I would expect to see, Bank name, branch/branch code and account number.
If someone could explain what to do with this single field I would be grateful.
3. A possible bug.
When the option 'Search supplier list' is checked under company setup one can only add new suppliers. When unchecked, one can access existing suppliers in the drop-down for editing. Not sure if this is by design or not. Maybe I need assistance in understanding the use of these search check boxes under Company setup.
The version of FA is v2.0.5
Once again, a great thank you to the developers of this fine application.
I have just downloaded the new document layout and it is great. I can once again continue with evaluating this fine piece of software.
Well done once again to the developers. Nice to see such active work on such a good project.
No problem. Keep up the good work.
/Andre
I have started to test/evaluate Front Accounting. I thank the developers for such a great product.
I sincerely hope that my comments are taken as constructive and not nit picking. After all, Joe has done an incredible job so far and should be applauded for his hard work.
As I work through FA, I will post the results of my tests/evaluations.
Purchase order PDF
Customer Number appears on the PO but is blank.
I feel there should be a field under Suppliers where this should be entered. Then it can be displayed on the PO.
Charge To has the Supplier Details.
Surely this should show our Company details as configured? In its present form, this infers that the Supplier is charging itself! If this corrected to show our Company details, where would the Supplier details be shown ? Extra space would be needed for the Supplier details.
Shipping Company appears on the PO but is blank.
I feel there should be an drop down in PO creation to choose a shipping company when creating the PO. Possible choice could be [Collect/Deliver/Shipping]
Due Date appears on the PO but is blank.
I feel there should be a field in PO creation (calender pop-up?) to choose due/delivery date.
Your VAT number appears on the PO but is blank.
I feel there should be a field under Suppliers where this should be entered. Then it can be displayed on the PO.
Our order number appears on the PO but is blank.
Our order number is already displayed on the top of the PO. This caption could be left off and the space used for something else.
Customers Reference appears on the PO but is blank
During PO creation a Suppliers Reference field is available but not referenced on the PO PDF. I feel Customers Reference should be the person to whom the PO is directed at the supplier and the Suppliers Reference should be the person creating the PO possibly getting this from the user name configured.
Item Code / Item Description
The Item description is under the Item Code heading with no Item Code displayed (This has been reported elsewhere).
I feel there should be an option to choose the display of our Item Code or the suppliers code or both somewhere under a configuration option, maybe under supplier setup on a per supplier basis, the choice defaulting to supplier code first. Should space(width) be an issue on the PO PDF, I would suggest 2 lines be use for the code and description.
For example
SUPCODE: XX123-FGR008 <- supplier code
20mm Widget with bell & whistle.
or
INTCODE: Widget20mmBW <- our code
20mm Widget with bell & whistle.
or
SUPCODE: XX123-FGR008 / INTCODE: Widget20mmBW <- both codes
20mm Widget with bell & whistle.
My example is not very elegant so maybe someone else has a better suggestion.
Delivery Date
I feel this is just a waste of valuable horizontal line space and could be moved elsewhere into the header. After all this would be repeated for every item on the PO PDF, possibly this could be combined/replaced with Due Date in the PO header.
Address at the footer.
I dont see the purpose of this here. I feel this should be removed and the space reclaimed.
Phone/Fax/email at the footer.
I dont see the purpose of this here. I feel this would be better served if it was part of the Charge To suggestion as discussed above.
Bank at the footer.
I dont see the purpose of this here. I feel this should be removed and the space reclaimed. Why a supplier should need to see a bank account on a PO is beyond me. What if we are paying cash.
Bank A/C at the footer.
As above.
General
I feel there should be entry fields for further supplier contact info on the Suppliers entry such as contact person/telephone/facsimile. We have the e-mail field already so it would be nice to have the other stuff as well. This should also appear on the PO PDF with the rest of the supplier info. So if the shipping Co. needs to contact the supplier the info is on the PO PDF.
Although I have little or no PHP or MySQL skills (bows down to Joe's skills) I would be happy to assist in sytem analysis and making graphical mockup-ups for discussion.
I look forward to the forums comments.
Regards
Pages 1
FrontAccounting forum → Posts by ITCynic
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.
