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
Yes, in 2.3RC3 changes were made related to TB_PREF. Now TB_PREF is set to '&TB_PREF&' pattern which is superseded by right preffix just in db_query(). This was necessary to enable right upgrade on multi-database installations (where).
Also I'm not sure about the right place for function definitions in extension file. Probably the better one would be below all include() lines.
Janusz
Unfortunately there is no javascript interface which would automatically open select list, but there is no need for mouse use. It depends on browser type, but in FireFox you can open select list using Alt-DownArrow combination, so you can leave your mouse apart 
.
Janusz
I would like to thank you guys, for all the important suggestions. We are busy now with final 2.3 release preparation, which is planned at the beginning of December. We will consider changes in this area just after the release, when we have more time and less constraints on database scheme changes.
Janusz
@ed10 In FA price list is related to transaction as a whole, and not the single item in transaction, so you are right - there is no way to use multiply price lists on the same transaction. You can consider this as an issue, but it depends on type of business. I guess you would like to have sales type selectable per line item?
Janusz
@jason_salis Well, I have read the thread and have done my best to help you understand how the program works. If you think I'm not right person to read it - it is not a problem, at least not for me. Good luck.
Janusz
Sam, can you really help us with chinese setup?
Janusz
Jason, I understand constraints you explained and this is somewhat obvious: nobody want to sell items below the costs. But in both your posts you have not mentioned about ItemandInventory/Sales Prices menu option, so I guess you simple overlooked it.
In short words logics behind prices system in FA:
. You can set exact price for every item/pricelist pair;
. Customer has one pricelist selected as default;
. When exact price is not set for given item/pricelist the price is calculated from base company pricelist.
I hope Tom has explained all this better than me, so maybe now it is more clear for you.
Janusz
No guarantee on mixed version behaviour. The sales_order script was also changed in CVS on November 6th, and can require other scripts changed at his date (see CVS CHANGELOG.txt)
Janusz
Really strange. I can't reproduce the effect. I guess you are using 2.3RC version, and not old 2.2.x. Maybe this is some browser related issue?
Janusz
Well, I'm not sure what is your conclusion, so I don't know whether I agree or not .
I would like to avoid words meaning discussions, but for us price list and sales type is merely the same: this is set of prices used in company for some sales segment, together with algorithms used for price calculation when exact price is not set for given item.
As a reply to your question 2: you can add sales type in Sales/Sales Types, and entry prices for just created sales type in Items&Inventory/Sales Pricing. Is this what you are asking for?
Janusz
Logo in reports is included in reporting/pdf_report.inc about line 53 (2.3RC version0.
Janusz
Unfortunately we have no specialized report generator so far, so to change the report content you need to know php language. Moreover reports does not use html at all as the reports are generated as pdf files. Anyway all the reports definitions are in respective repxxx.php files, together with related sql queries used to retrieve reported data.
Janusz
Maybe better solution would be some automatic 'internal' ordering when some ordered goods are absent in inventory. Often the salesman have no access to purchases which are confirmed and processed by purchase officer.
BTW when I click add item in New Sales Quotation Entry or New Sales Order Entry the new item is not displayed, but is put into db.
I'm not sure what you mean here. Could you explain me the problem?
Janusz
Currently we are focused on final 2.3 release which is planned at the beginning of December. The work order improvement is not so easy, and in fact the better way would be to redesign the manufacturing module than make local changes like the multiline WO. In fact manufacturing process is much more complicate than simple sales, while (still incomplete) Sales module is more complex than Manufacturing in FA. This is meaningful 
.
Anyway if there is somebody really interested in manufacturing improvements, who can spent some time on database analysis and redesign it would significantly speed up development in this area.
Janusz
Ed, we use only 'flat' popup windows i.e they are used only for temporary view or selection of customer/supplier to document. This is design policy which make program flow easy and help avoid burden on a desktop. To not forgot what has to be produced you can open view transaction popup just before following WO link, and closing it after the last item is produced.
The real cure for all this is to implement SO=>WO convertion, which is impossible until we will have multiline work orders coded.
Janusz
Tax configuration was explained a couple of times on the forum Use search utility.
Janusz
Yes, you are right. As every sales document in FA database is related to single company branch there is no way to combine documents issued for different branches. To change this you have to redesign sales module including database scheme.
Janusz
Sorry, I mean bug report 274 and attached files.
Janusz
Yes, I agree about quantity control in purchase module - this surely should be improved, and optional warning/blocking should be selected on purchase/item basis using additional option in Items/Purchasing Pricing. But what about weight & dimensions? The only reason for adding this would be freight costs calculations which are not implemented so far.
Janusz
This is a bug which was resolved some time ago. Look at Mantis bugtracker report 273. Here you will find changed files.
Janusz
Allowing or not change of prices by salesman is part of company's internal policy. Unfortunatelly readonly access to price field is not supported in FA for now, but this is good candidate to be implemented in next releases.
Janusz
This is intentional design decision. To enter right GL items you have to have some accounting knowledge. Average guy responsible for purchase invoice entry knows nothing about it. Therefore having GL interface here is more asking for troubles than advantage. Nevertheless old purchase invoice interface still have GL items, so this one can be used in special cases.
All what can be achieved with GL items you can also achieve by setting special items for freight costs etc to be entered as additional invoice line.
Janusz
Adding more fields in Items is not a problem (in next release - 2.3 database stucture is frozen), but how you would like to use it in PO. Just as read only information displayed after item is selected?
Janusz
I think this is only matter of naming. Price list is normally related to sales type. Nevermind.
You can entry actual prices for Items& Invenotry/Sales Pricing. There is also multilevel guess system for not defined prices, but you are right - finally the price is not directly related to cost of purchase, but eventually to price in default (base) pricelist.
Janusz
Internal bookkeeping, and also inventory valuation is processed in home currency, so there is no easy way to accomplish your goal. I guess you will need some additional routine to revaluate inventory on demand.
Janusz
FrontAccounting forum → Posts by itronics
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.