The US one-cent coin, i.e. the penny, is the fundamental unit of U.S. currency. Children learning about money are often taught how to count starting with the penny. Loss of the penny as a basic part of U.S. currency is unfortunate as we instead migrate towards vague, intangible, digital currency concepts.
Recently, we were contacted by a point of sale user in Washington state who indicated that their bank can now no longer supply them with one-cent coins.
So what are retailers that need to "make change" for cash payments supposed to do?
Round. But "rounding" leads to more questions. Round up to the next (higher) five cents? That approach may be available in some states but is generally frowned upon. A number of states have already passed laws, including Washington state, that requires symmetrical rounding. While there may also ultimately be federal legislation, a common principle that has evolved (for the 45 states plus the District of Columbia that have statewide sales taxes) is that you cannot round off sales tax, and that the exact amount of sales tax based on the original sales price must still be calculated and collected.
There is also a bit of a catch-22 problem since in point of sale (POS) cash transaction handling, you don't know whether a cash payment is going to be involved (and hence potential cash back) until towards the end of the transaction when the customer tenders payment.
In eliminating production of the penny, Congress was not consulted, and while the decision ultimately might have been the same, this was more of a unilateral decision by the U.S. Mint following a directive from the White House due to the high cost of producing the penny. But that analysis failed to consider consumer and business impacts of this decision which now will require somewhat unintuitive software logic changes (and related upgrade expenses by businesses), and also because different states could end up having different requirements for businesses to follow. This then leads to higher consumer prices.
In solving the issue for POS applications in our accounting software program, we have spent an unfortunate amount of time on what seems like a very simple problem. The total, after tax, has to be rounded either up to the next five cents or to the closest five cents (depending on what is allowed) but without making any change to the taxable sale amount since sales tax has to remain unchanged.
To avoid making more invasive changes to the system (which in the case of our system could also change the sales order module programs because POS transactions when posted in our software become part of sales invoice history) and to avoid adding any changed data structures (such as a new "total only" adjustment field which could operate sort of like the highly unpopular gas fuel surcharge for sales invoices some years back), we decided to automatically add a line item adjustment (marked as non-taxable to avoid any sales tax changes) that represents the difference between the actual total and the rounded total. This allows us to maintain the normal internal logic whereby the total of line item extensions equal the POS ticket's subtotal plus tax (and in the case of sales orders, freight). By making the penny adjustment of +- 0.01 to +-0.04 as a line item, the taxable basis for sales tax remains unchanged and allows any cash back (which is where the real problem is) to be calculated based on the "five-cent" rounded amount (and hence no pennies required).
Unless cash back is involved or some other form of payment is made, then nothing changes; the forced line item and rounded total only comes into play if cash tendered is greater than the sale amount. Some technical details as to the conditional rounding calculation is contained below (although that doesn't get into most of the in-line logic required within the POS application itself, but rather just the "rounding" calculation). The end result is that:
$10.01 or 10.02 rounds down to $10.00
$10.03 or 10.04 rounds up to $10.05
$10.06 or 10.07 rounds down to $10.05
$10.08 or 10.09 rounds up to $11.00
This new logic will now be incorporated as standard in Advanced Accounting's POS-A ("Run POS Register") option going forward. The end user will need to input a new non-inventory item called PENNYADJUST under "Enter/Chg Inventory" and use a general ledger (GL) sales code linked to either the over/short GL code specified in POS-J (POS configuration setup) or any desired income or expense GL code. Older users that utilize sales orders for point of sale activity will have to manually enter the adjustment.
Technical details concerning five-cent rounding (included here mainly for programmers or for those who are curious to know more about a fairly boring topic):
As indicated above, the trigger for rounding happens only if (a) there is a cash transaction and (b) cash back is required due to an amount tendered that is more than the sale. Nothing changes with a credit/debit card, ACH, or check payment.
When the initial request we received (in connection with the penny shortage) was to always round up to the next "nickel" (something, that as it turns, out isn't evolving as the standard approach), we first turned to the CEIL function, which has existed in the TAS Professional (and newer) programming language for a very long time. In version 4.0 (1992) it was called CEILING. Then, in TAS 5.0 through TAS 5.1 (1995 to 1996 releases) it was changed to simply CEIL. Those were all 16-bit versions. In the newer 32-bit version, we continue to have a CEIL function (which is also a Delphi/PASCAL function). The rarely used CEIL function returns a whole number that is the closest value equal, to or greater than, the field value of interest. Because 1/20 = 0.05, the "trick" is to multiply the CEIL() result of the desired field by 20 and then divide that result by 20. In the TAS language, this is represented by:
define newtotal, oldtotal type N size 14 dec 2
newtotal = CEIL(oldtotal * 20)/20
The above approach however, does not satisfy the symmetrical rounding concept which is the more equitable approach and is favored by states and other authorities (and in some cases required legislatively).
A Dephi function that does this is:
function RoundToNearestNickel(const AValue: Currency): Currency;
var
TotalPennies, Remainder: Integer;
begin
// Convert currency to total integer pennies
TotalPennies := Round(AValue * 100);
// Get the modulo 5 to identify the trailing digit
Remainder := TotalPennies mod 5;
//Apply symmetrical rounding rules
case Remainder of
1, 2: // Round down to the previous nickel
Result := (TotalPennies - Remainder) / 100;
3, 4: // Round up to the next nickel
Result := (TotalPennies + (5 - Remainder)) / 100;
else // Already ends in 0 or 5 (no rounding needed)
Result := AValue;
end;
end;
An equivalent TAS Professional/Premier function follows:
define TotalPennies, Remainder type I size 5
define newtotal, oldtotal type N size 14 dec 2
func RoundNearest5 oldtotal
TotalPennies = Round(oldtotal * 100)
// Get the modulo 5 to identify the trailing digit
Remainder = mod(TotalPennies, 5)
// Apply symmetrical rounding rules
//(verbose approach to match the Delphi version)
select Remainder
case 1 // Round down to the previous nickel
newtotal = oldtotal-(Remainder*0.01)
case 2
newtotal = oldtotal-(Remainder*0.01)
case 3 // Round up to the next nickel
newtotal = oldtotal+(0.05-Remainder*0.01)
case 4
newtotal = oldtotal+(0.05-Remainder*0.01)
otherwise // Already ends in 0 or 5 (no rounding needed)
newtotal = oldtotal
endc
ret newtotal
//another more concise way to write the above select/case/endc loop
//since the TAS case statement does not allow more than one parameter
//is:
if remainder=1 .o. remainder=2
newtotal = oldtotal-(Remainder*0.01)
else_if remainder=3 .o. remainder=4
newtotal = oldtotal+(0.05-Remainder*0.01)
else
newtotal = oldtotal
endif
In the TAS 7ix samples folder, we have added a program that performs either of the foregoing calculations:
