Workflow Sample: Episode 479: Cautions for Letting "Prorating" to Script Step

Want to automate "Prorated billing".

Rent, Water charge, Cloud service... In any field, "invoicing process" is a very important business. No mistake is allowed. Even though a human would do the credit investigation and address input, I want to let a computer do the calculation of "prorating".

Indeed, a computer is a machine.
It makes no mistake.
And it is fast.

But on the other hand, it also has stupidity such as, one third multiplied by three equals "0.999". There is not much difference about this aspect between a calculator and a supercomputer. (Oh, I hear voices of objection from users of J programming language, etc.)

In the following Workflow, prorating calculation for "a service which monthly fee is 10,000 JPY" is automated.

It is a simple sample flow that, inputting information of "used X days in month MM of year YYYY", then automated until "generating of invoice PDF".

In this example, as obvious on the flow chart, even an "Approval Step" or a "Send-back Step" is not arranged for the sake of simplicity. A very plane Business Process. Therefore, it is useful as a base for the development of applied system, such as "printing out automatically" or "automatically transmit email with attachment".

[Invoice Issuance flow]

Computers does not handle "Fraction" very well. It cannot recognize even "one-third" properly.

Therefore, there could be cases where the degree of confusion is deepened by "calculating" such as addition and multiplication.

By the way, a "software to calculate in remain fractional", that is not so useful in real society, is often utilized as teaching material. Students need considerable ingenuity just for "inputting fraction" or "displaying fraction".
(Furthermore, simplifying a fraction or equalizing denominators are profound...)

At the automatic Step in this Workflow, I have let such a computer process of dividing the "monthly fee" by "31" and "30". Basically, it is in the method that continues to hold the decimal number without truncating and rounding at the last.

Incidentally, you should note that you need to define conditional expressions carefully. For example, it could become a situation that "calculation result of monthly fee for use of 31 days is not equal to 10,000 JPY, if you thoughtlessly set "Truncate after the decimal point".

[Invoice Issuance flow: "1. Enter Number of Days Used" screen]

Setting of Script Step "Prorating" （Server Side JavaScript）

//// == Retrieving == 
var monthlyCharge = data.get("●") - 0; // javascript Number 
var targetYearMonth = data.get("●"); // (*1) 
var daysOfUse = data.get("●") - 0; // javascript Number 
// *1: M230. com.questetra.bpms.util.AddableDate() 

//// == Calculating == 
var daysOfMonth = targetYearMonth.getLastDateInMonth().getDate(); 
var perDiem = monthlyCharge / daysOfMonth; 
var billing = perDiem * daysOfUse; 

//// == Updating == 
retVal.put("●", java.math.BigDecimal( daysOfMonth ) ); 
var perDiemJmode = new java.math.BigDecimal( perDiem ).setScale(2, java.math.BigDecimal.ROUND_HALF_UP); 
retVal.put("●", java.math.BigDecimal( perDiemJmode ) ); 
var billingJmode = new java.math.BigDecimal( billing ).setScale(0, java.math.BigDecimal.ROUND_HALF_UP); 
retVal.put("●", java.math.BigDecimal( billingJmode ) );

[Data Items list]