Equation into a custom field & sum into another custom field

Hello Friends; Greetings from Rusty Old Palestine;

Today I would like to discuss with you if it is worth while to allocate resources to this feature:
[adding an equation box to custom fields, which multiply, divide, add, or subtract numbers and then calculate and send the sum to another field]

My Team -which is a Saas Company in Palestine- really needs such a feature, it has been requested from at least 4 customers so far.

After much discussion within our small team; we really can’t find anything worth more work than this feature; manager can easily adapt to any organization; which set’s it up from any other software; this feature will make it the best adaptable software in the market -for people who do not know code; which is 90% of population- [all of us are ready to put work into this -3 developers-]

What do you think?

Brilliant idea, it would be really great

1 Like

I agree

The latest version (18.7.64) allows to set custom field to number type. This allows to do these calculations using custom themes.

Let’s say you have two custom fields:

  • Field 1
  • Field 2

and you want to show on invoice Field 3 which is total of Field 1 and Field 2

All you have to do is inject following lines to your custom theme:

<div style="font-weight: bold; padding-top: 20px">Field 1 + Field 2</div>
<div>{{ custom_fields["Field 1"] | plus: custom_fields["Field 2"] }}</div>

The most important is {{ custom_fields["Field 1"] | plus: custom_fields["Field 2"] }} which shows how to do addition of two custom fields.

And the result:

1 Like


It’s possible to do addition a standard field + custom field;
e.g. Invoice Total + Custom Field.

Check the latest version (18.7.72).

You can now do something like:

{{ table.totals["Total"] | plus: custom_fields["Field 1"] }}


{{ table.totals["Balance due"] | plus: custom_fields["Field 1"] }}


1 Like

lazy question: what happens if you change an existing custom field from “text” type to “number” type?

I have used a custom text field to store numbers but would like to change it to a number field now but do not want to lose my existing values.

I changed an exiting text field to a number field and the data I had already entered remained and was now formatted as a number :slight_smile:

Regarding to this thread, I have another specific question.
In my business I sometimes have to deal with rights.
This means that a percentage of my article price should be invoiced as rights (with a different VAT).

This should become…

User Rights €87,5 6% €92,75

First line = services at 65% of the amount.
Second line = rights at 35% of the amount.

Now, I have to do this manually.
Is there a way to do this with custom fields?
Something like adding a number custom field on an article.
If this number is not blank (the percentage of the rights), automatically calculate the rights and put it on the line below. AND, change the total price of the article to 65%.
I suppose this can only be done when generating the invoice because?? But what could be the code?
Or should I use 2 custom fields with both percentages?

Thanks a lot!!!

Do the two lines have different vat amounts? In this case you must have two lines in the invoice.

You cannot do anything close to what you describe, @Bart_De_Jonge. Tax codes cannot be applied to custom fields, only line item amounts, which cannot be involved in calculations with custom fields. Taxes are interwoven through the hard coding in some fairly complex ways. Those calculations have to be done by the program and posted to correct accounts. The type of calculations described in this thread are for display purposes only. They do not store information or post amounts to accounts.

Yes you’re right…
Off course…
Even the totals in my list of invoices wouldn’t be correct regarding to the generated invoices. Stuped me!
Do you see another solution for this @Tut?

If your job or hourly rates are standardized, you could create non-inventory items for editing and user rights. The sales prices (per job or hour) could be fixed at your desired ratio. Tax codes for the different rates could be set for each non-inventory item. Separate posting accounts could be selected, if desired.

Then, let us say you edit your movie. You would enter the editing item, quantity 1, and on another line the user rights item, quantity 1, and you would have your total. This would be the routine for a fixed rate.

For an hourly rate, you would enter the hours as the quantity for each non-inventory item. The ratio would be preserved, proper tax codes applied, etc.

It would all be fairly automatic and avoid the need for tedious calculation for every job. Set up the non-inventory sales prices per job or hour once.

Hi @Tut,
This is exactly what I do now.
The only difference is that I only use 1 non-inventory item ‘rights’ for everything.
Because I have for some clients different prices, and that should create too much ‘rights’-items.
I was wondering:
Can’t I work with discount 35% per line on the editing item, and then use the rights-item as follows:

line 1 : editing 1 €250 discount 35% €162.5
line 2 : rights 250 €0,35 €87,5

Then change the layout to not print the discount, and adding a custom column to indicate the rights percentage…?
Better would be adding a functionality of calculated fields :wink:

Your approach gets into a lot of problems. You would have a unit price, an invisible discount, and a magically different amount. And the code to eliminate the discount column would not be trivial, possibly blowing up the layout. (I don’t know.)

You also encounter the problem that in-line custom fields cannot be set as numbers. So no calculations are possible with them using Liquid’s arithmetic filters.

This would involve very significant changes to the program. You are talking about calculations involving multiple line items. Everything in Manager is structured on a line-item basis except the totals.

A post was split to a new topic: Calculating total of column

wow, thank you, this software keeps impressing me more and more with each passing day

3 posts were split to a new topic: Name of withholding field