1,976

(7 replies, posted in Accounts Receivable)

Hi Andre,

ITCynic wrote:

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

Yes, and it is how list selector is designed  to work, to minimize number of database queries. In fact the units and price fields are updated right and once: just after selection of item to order/invoice from the list. Of course you are right - it is easy to skip price update, but this should not happen when data is entered in one of two natural ways:
. using mouse: selecting item from list
. using keyboard: entering item code and eventually selecting right item  from list, in natural sequence.

All operations you have described can be done, but I see no reason to pay with additional database queries to eliminate this. Once again: salesman can change the price as he wish, so there is no additional security risk with the potential price change "backdoor" you have described.

ITCynic wrote:

I love your comment "random bad people" ....................  smile Here in South Africa they are not so random.

Yes, this is truth all over the world, not only in SA. When writing our software we made some assumptions. One of those is that the company does not provide access to the application interface for peoples other than staff members. Do you have another policy in your company wink ?

Janusz

1,977

(7 replies, posted in Accounts Receivable)

Well, frankly speaking I see no big problem here. Price is updated after change of selector, when the selector loses focus. It means that to enter erroneous data (wrong price) you have to intentionally omit list selector after item code change. I think it is mainly theoretical problem as experienced users (those knowing the item codes) prefer to use keyboard instead jumping with the mouse on whole screen. Last but not least we cannot say here about abuse vulnerability as invoice page (and all other) is for company staff access only, and not to be used by random bad people.

Nevertheless some warning when price entered by hand differs too much from those stored in system would be useful here. Just simply as protection against user mistake, not intentional abuse.

Janusz

1,978

(7 replies, posted in Reporting)

I think you should first check if lpr command works at all on your computer locally, and next  configure network printer services. I don't know what distribution do you have, but certainly some rpm or deb package should be installed together with cups-common to enable emulation of BSD print services. On Debian it is cup-bsd package.

Janusz

1,979

(7 replies, posted in Reporting)

Printer Name - is short printer identifier

Printer Description - longer description for users (e.g. printer location or type of printer - color, fast laser etc).

Host name or IP - this is printer (local or inet) IP or printserver name. This can be localhost (when print server is on the same computer as FA server), or any site  name as known by related DNS or bind service.

Port   - printer daemon listening port. Currently the only supported protocol is lpd, and default port for this service is usually 515.

Printer Queue - printer queue name (see man lpd).

Timeout timeout on network connection to printer server in seconds. default is 20.

To list your printer queue on linux you can issue: lpq -a command. Printer name is displayed in the form: queue_name@local_name.

If you wish to use cups server you should enable lpd sevice in it. See cups documentation how to set it.

Janusz

1,980

(4 replies, posted in Accounts Receivable)

You mean you have document reference in form WFN50XX ?
Yes, it can be a problem. Maybe we should add also searching by reference in Customer Inquiry.

Janusz

Probably you have broken database consistency as a result of manual playing with database content. AFAIK there is no one place in source code where 'DEF' hardcoded, and the problem is that you have deleted location record, while it is referenced in BOM.

But if the deletion was made normally at Inventory Locations page it mean there is lack of some pre-deletion check as Joe said. Anyway it can be a bug, not a design flow.

Janusz

1,982

(10 replies, posted in Setup)

itronics wrote:

Time printed on reports is current server local time as returned by php date() function .
see php documentation and function Now() on file date_functions.inc.

1,983

(2 replies, posted in Translations)

Some strings (like transaction names) are retrieved from database, so they also should be translated in localized chart of accounts sql package.

Janusz

The planned changes cannot be included in version 2.1.3. Minor releases contain mainly bugfixes, and ANY database changes are prohibited. This fundamental development policy is not subject to change, as this is the only way to ensure any minimal  FrontAccounting stability.

So if you are in a hurry, please download CVS version after planned 2.1 branch merge merge and work on it.

Janusz

First please set pdf_debug to 1 in config.php temporarily. In this mode you will download generated pdf code instead of pdf report, but you should have displayed eventual error messages. Turn debugging off after the test. This should help in tracking the problem
Janusz

1,986

(5 replies, posted in Accounts Payable)

When you create Quick Entry with type Supplier Invoice/Credit you can use it during purchase invoice entry. Here you have to select the right Quick Entry and input needed charges amount. That's all.

Janusz

You are right. We will look at this.

Printing is implemented currently only for some documents, this is not the Journal Entry case. But yes, here was problem with View or Printing Transaction table update.  Main CVS updated. Thanks.
Janusz

1,989

(9 replies, posted in Reporting)

Thank you very much maasj. This was a bug in dimension selector generation. Main CVS has been fixed, affected file reports_classes.php.

Janusz

For deposits you should select one of available accounts as source, so if you have defined bank account with name 'Current Account' it will appear in 'from' selector. It should also appear in Bank Accounts maintenance screen. If not - something is broken in database.

Janusz

1,991

(3 replies, posted in Setup)

Thanks Courtney. This is for saving scanned copy of external documents like purchase orders and so on. Truly optional.

Janusz

Oh, yes, I forgot about this well known apache+gettext issue. After changing languge *.mo file http server should be restarted. I was looking for some smarter solution, but restart seems the only choice. Thanks alerjeb for the advice.

Janusz

1,993

(38 replies, posted in Wish List)

Hello Alvin,

Interesting link, although this is nothing we can do about FA-POS synchronization. As far as I understand SymmetricDS have to be installed both on client and server machines, and it access MySQL database directly. Theoretically all what is needed to use it is installation and proper configuration, so anybody  interested can try e.g. to build a bridge between FA and any POS.

Anyway thanks for information -  pdf documentation explaining implementation approach is inspiring.

Janusz

1,994

(7 replies, posted in Installation)

No, those strings are fetched from database, so when not translated they are displayed in english.
Janusz

This bug was fixed by Joe two days ago and the fix is available in CVS main.
Janusz

1,996

(7 replies, posted in Installation)

They are used in Forms Setup (forms_setup.php).
Janusz

1,997

(7 replies, posted in Installation)

Not all data can be included in source (e.g. names in chart of accounts), so sql file have to be translated in some places as well if you wish to have all names localized.
Janusz

1,998

(7 replies, posted in Installation)

Those are types of transactions used by FrontAccounting you should translate type_name  leaving other fields intact.
Janusz

Hello Renier,

I do not want discourage you, but any integration is big piece of work. If you really have not programmed yet in php this is not how you should start. Less discouraging for you would be e.g. testing new functionalities added in unstable version and tracking down bugs still existent in the code.

But if you do have some experience with php/mysql, you can of course try to integrate FA with some third party software. The range of applications you have encountered is very wide, so first you should know what you want. I think the best choice is the one which is most usable for you. If you will have some detailed questions about FA internals, or you would like to consult design plans with us to choose the best implementation, please start related thread on this forum. We always do our best to help new developers.

Thanks for your offer and you are welcome

Janusz

2,000

(2 replies, posted in Items and Inventory)

Yes, seems that removing 'where'  option from stock_purchasable_items_lists_*() in ui_lists.inc should be enough.

Janusz