Showing posts with label Legal. Show all posts
Showing posts with label Legal. Show all posts

Wednesday, June 18, 2025

Monetary Value Round Off -- A Legal and Business Problem

 

I read a blog post from Gaurav Khurana suggesting on round off of a number having decimals.  This is the post.  What made me curious is that number and what it meant.  It was a discount money having decimals.  Here, the number of decimals was not restricted to two.

Gaurav, said, it is a better experience if that discount amount is restricted to two decimals and rounded up.  Initially, I see, this is a fair expectation.

Here is the pic of a bill which Gaurav has shared.  I'm using it here on his permission.


I woke all of a sudden at 2:18 AM today, and I relooked into the post and that value whose decimal is not restricted.  I said myself there is something which cannot be rounded up or rounded down here and I could interpret it for a context.


Interpretation of the Value and its Meaning

  1. The "Bank Discount" showed the below amount
    • - 450.90999998999996
  2. The amount is in Indian Rupees
  3. This amount tells, it is the discount offered by the Bank on that transaction
  4. On round up, it will be,
    • - 450.91
  5. If I use the round up value, then the "Balance Paid" amount will be,
    • 4,058.18
  6. If I do not use the round up value, then the "Balance Paid" amount is still,
    • 4,058.18
  7. If I do not use the decimal values in "Bank Discount", then Balance Paid is,
    • 4,059.09
      • That is, I will have to pay 0.91 rupee (91 paisa) more.
    • In this case, someone is at loss.  Who?
      • Business?
      • Customer?
        • In the context of this bill, it is, customer who is paying.
        • Customer will pay 91 paisa, which is, almost one rupee more.
          • Now, imagine, the profit which business makes from all its customers for not having that decimal values in the amount!
        • Is this right?
The meaning and value of Balance Paid is not affected, in both cases, that is,
  • When I use Bank Discount value as is with decimals.
  • Or, When rounded up with two decimals.

My question is,
We should have check on decimals shown and used.  But, should we round up the number when it is of monetary significance and value?


Why I have this question?

  • Refer to the below examples.
    • 450.35
      • On round up, it will be 450.5
    • 450.55
      • On round up, it will be 451
If observed, on round up, the amount discounted is in excess by 0.15 rupee, that is, 15 paisa; and, in the case-2, it is in excess by 0.5 rupee, that is, 50 paisa.

If the bank loses these paisa for each transactions of same customer and other customers, won't the bank is shelling out the money?  Is this good?

Likewise, if I have to pay 0.15 paisa and 0.50 paisa, am I not paying more?  Then, imagine the big amount that business is making by rounding up a monetary number and making its customer pay in excess.


My Thoughts on Monetary Value Round Off

  1. The monetary value should not be rounded up or rounded down.  
    1. But, it can have a decimals and limited to two or to what business sees manageable.
      • As Gaurav said, decimal to two digits makes life easier for all is my understanding.
    2. The customer need to see this monetary value.
  2. The generated bill or transaction should have this detail.
  3. When making a payment, the billing system, can show a round off value.
    1. And, the business should decide upon, should the amount be round up or round down
May be to avoid such arguments and discussions in the billing counter, today, the bill amount will be a whole number and not a number with decimal.

Such round up instances can turn to a legal problems for the business.

I have noticed, the business offering round down on a monetary value, at times.  Also, I have noticed, certain consumer mobile apps showing rounded up number without breaking down the bill details.



Whatever, as a Test Engineer, I and you, have to create a report [ticket] for product's reference; keep the stakeholders informed of such behavior in the system by explaining the impact to business in monetary and legal aspects.





Friday, January 10, 2025

Caution! Know This Before You Prompt For Your Testing


My Fellow Test Engineers,


If you are using Gen AI and LLMs as an aid to do better work, yeah, we should be exploring it.  I have no second thoughts in it.

Are you giving anything bounded by NDA to Gen AI models and LLMs?
  • Like a part of software requirement, video, an image, code or anything that hints what the system is?
    • That is, is this part of your prompt text which you are giving to the Gen AI model(s) and other LLMs?  If so, do exercise the below questions:
      1. Do my organization and its business see any threat and risk from me for doing so?
      2. Does it violate the NDA (Non-Disclosure Agreement)? If yes, how will I be impacted and prosecuted by the employer's business and organization?
      3. Will I be terminated from my job or contract for doing this?
      4. Will I have to face the legal consequences?

I tell you, for today's LLMs, it is sufficient to have gist of requirement or code or video or an image to isolate one's request. From there, it can monitor fairly better with additional anticipation.


My questions:

  1. How would you trust the models behind?
  2. Do you know how it is observing especially when you use your business identity to login and prompt?
  3. Though you have customized the LLM's model and it is in within your environment, how do you know it is not connecting to its vendor environment and updating the gist?

Let us leverage the prompt engineering, Gen AI and associated LLMs. But, be aware and conscious of what we are giving out!


Also, be aware of what you tell to fellow test engineers. Not all Test Engineers or SDETs think of the consequences; instead just blindly mimic or follow what is being done or said to do by trying and using it.


Let us think about what we are passing to community by just saying to use prompts for --  to write test cases for this given requirement; read the given requirement and give a test design and strategy; review the code snippet and more.  Such loose and vague messages can be harmful if it is blindly followed!

By prompting the text and calling it out as prompt engineering, we might be giving out what we are not supposed to in the context of our employer's work. Caution!