Search options (Page 4 of 97)

Yes, indeed, seems this was leaved unfinished in 2.4RC development. Fixed.

@subodhonnet
You probably haven't enabled LDAP php module, and application execution hangs on call to unexisting ldap_connect() function.
Additional check has been added during module activaton, and new module version is already uploaded to FA extensions repository.

If you would like to continue tests from this point, just remove Auth_LDAP configuration from installed_extensions.php file (also in company/* folders), remove /modules/auth_ldap folder and try login again. Now you can install fixed module version if you wish.
Thanks for reporting this problem.

Janusz

Ironically all the extensions does not suffer this bug. This change was overlooked in the main code only.
Janusz

Following our non-written coding policy regarding sql statements (like using capital letters for sql keywords) there is no need for additional cleanups here :-).
Janusz

Yes, indeed in default_get_dispatchable_quantity() the last line was sparse. Fixed in repo.
While this hook is not used in main code, it can be used by extensions.
Janusz

I'm not sure what you have missed (maybe you have changed sides in Journal entry?), but it seems there is no bug here. I have just tested the scenario on demo.frontaccounting.com. Look here: there is Sales Invoice 234/2017 and identical Journal Entry 107/2017 entered today. Please generate tax report for 12/10/2017 and you will see both transactions are taxes exactly the same, with correct sign.
Janusz

@ApMuthu,
I don't think so. Now user can easily accept proposed next reference, or change it if he wish, at the low cost of one additional Ctrl-Enter keypress. In alternative scenario, changing once stored invoice is much more unhandy.
Janusz

{P} placeholder in reference template is replaced with current user's POS id, but I guess it is rather rarely used. Main reason is than there is no easy way to change the POS id, as this is internal record id assigned to POS definition when it is created.

Janusz

In response to another problem:

there was exchange rate display bug indeed, which just has been fixed in our repo.

Thanks.
Janusz

Fixed 5th issue, 3th need further debugging.
Janusz

The file cannot be included into sources in current form for a couple of reasons:

1. Some fields in database are not updated leaving it in inconsistent state:
recurrent_invoices.debtor_no
sales_orders.debtor_no, sales_orders.branch_code
gl_trans.person_id - for some transaction where person_type_id is set to PT_CUSTOMER

2. For security reasons additional access to this feature should be restricted to users with special rights (company admin), so additional access level have to be defined in access_levels.inc and included in sql files. If the file is to be distributed as extension module, this can be defined in module.

3. Due to potentially disastrous effects, the warning displayed on the page is not enough. Additional confirmation step should be used before customer merging is done. this mechanism is used e.g. in Setup|Void Transaction page, and can be reused here.

4. The code should be at least roughly consistent with those used in the rest of application (e.g. using defined output helpers instead of raw html echo, or sanitizing sql with db_escape() function). These requirements have kept the code maintainable so far, and we want to continue this in near future.

Beside that, the feature looks interesting indeed, especially for novice users or in multi-salesman setup, where multiply customer records are not so rare.

Janusz

One more thing: I see that on 'price included' screenshot, the long tax description have pushed price much to the right side, which is a little misleading (the tax value lands near in same column as the rest of calculation, while it is not to be added here). I just have fixed it in repo.
Janusz