Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Include MathPHP's finance fuctions in Dolibarr #22742

Closed
atm-florianm opened this issue Nov 3, 2022 · 1 comment
Closed

Include MathPHP's finance fuctions in Dolibarr #22742

atm-florianm opened this issue Nov 3, 2022 · 1 comment
Labels
Feature request This is a feature request Issue Stale (automatic label) This issue is stale because it has been open 1 year with no activity. Remove this label to keep open

Comments

@atm-florianm
Copy link
Contributor

atm-florianm commented Nov 3, 2022

Feature Request

Including MathPHP, a mathematics library, to make some financial (among others) calculations more flexible and more reliable.

Use case

I am currently working on improvements to the Loan module. It currently uses its own calculation formula to compute installments including compounded interest. As far as I can tell, the formulas are correct, but they use implicit parameters (hard-coded constants that should be parameters). The features I am working on require more flexibility in those formulas, but the current formula is not documented and therefore hard to modify without risking introducing errors.

Current implementation in Dolibarr:

    function calc_mens($capital, $rate, $nbterm)
	{
		$result='';

		if (!empty($capital) && !empty($rate) && !empty($nbterm)) {
			$result = ($capital*($rate/12))/(1-pow((1+($rate/12)),($nbterm*-1)));
		}

		return $result;
	}

The calculation is correct (as far as my testing goes), but it will only work with an annual proportional rate for monthly installments in arrear. I am trying to enable (for instance) quarterly installments in advance (the rate will still be annual + proportional with the features I am trying to introduce, but it will be explicit to avoid any confusion).

I could implement my own calculation function, but I think there are clear benefits if we use MathPHP for those calculations:

  1. very generic functions
    1. no implicit / hidden / hard-coded parameters
    2. no dependency to a specific business object, can be used anywhere in the project
    3. when possible, functions have the same name and signature as their counterpart in common spreadsheet software (Excel / LibreOffice Calc) → programmers who are already familiar with spreadsheet (personally I am not) will have less difficulty understanding code that uses those functions
  2. specialized and unit tested: I believe it will do a better job than me if I implement my own formulas (I am not a trained expert in financial mathematics)
  3. whenever possible, function parameters are standard PHP types (arrays, ints, floats…): no need to learn unnecessary new APIs
  4. well-documented (not perfect, but it sometimes provides sources + detailed explanations)
  5. feature-rich
  6. not too heavy (less than 2 MB without unit tests and .git, 5MB if you include them)
  7. if necessary we can choose not to include the whole library, but only the parts we need (for instance, the financial part (Finance.php), which is what I need today, is completely independant of the rest of the lib. Finance.php only weighs 27 kB
  8. the license (MIT) is compatible with Dolibarr's GNU GPL

Suggested implementation

No response

Suggested steps

No response

Copy link
Contributor

github-actions bot commented Nov 7, 2023

This issue is stale because it has been open 1 year with no activity. If this is a bug, please comment to confirm it is still present on latest stable version. if this is a feature request, please comment to notify the request is still relevant and not yet covered by latest stable version. This issue may be closed automatically by stale bot in 10 days (you should still be able to re-open it if required).

@github-actions github-actions bot added the Issue Stale (automatic label) This issue is stale because it has been open 1 year with no activity. Remove this label to keep open label Nov 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature request This is a feature request Issue Stale (automatic label) This issue is stale because it has been open 1 year with no activity. Remove this label to keep open
Projects
None yet
Development

No branches or pull requests

1 participant