When doing this sort of work you need to know what data types you are working with and their allowable ranges.
In this case things appear to be OK since 20 * 1000 gives you 20000 which is in the -32768 to +32767 range of a 16-bit signed integer.
In other cases Y=MX+B can get you in trouble. The X and Y may fit into the integer but the intermediate result (MX) may overflow. The programmer needs to know how (or if) the PLC can handle that. Some PLCs may convert everything 'inside' the equation to floating-point ('reals'), do the math, and then do round-off to get the integer result.
With some PLCs you have to specify the data types for all math so you may need to convert the inputs to reals or double integers. This takes more code but it gives you more control over what the PLC is doing.
Those of us with long memories remember how challenging it was to get an integer remainder from an integer division in a AB PLC-5. Or the Square D Model 300 which may have been the first machine to allow expression editing similar to the Allen Bradley CPT instruction - except the math blew up if intermediate results went over 32767. They took care of that in their later Model 400 CPUs.
A modern temptation is to dismiss all this as old-man rambling and just do everything in floating point. That's OK most of the time - until you start doing EQU and NEQ comparisons or some other things.
The point of this sermon (or rant if you see it that way) is that some thought needs to be given to what is going on in the PLCs head before doing math in it. Be aware of the size limitations of each datatype that you are using.
I've mentioned before on this forum a couple of examples of botched numeric programming. Search the internet for them. There was the French rocket that blew up 47 seconds after it left the ground - trying to overflow a signed 16-bit register. And the patriot missile that missed the SCUD and several people killed - using floating point for a totalization that should have been done with a long integer.
As a profession - and for our customers - we need to do due diligence when programming math.