- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Which is precisely what they do when reporting to Uncle Sam but not when dealing with each individual customer. So the extra few cents per purchase that the customer is led to believe is rounded-up sales tax, never makes it to Uncle Sam.
If the sales tax were calculated from the individual receipts, the company would have no reason to want to keep the "feature", in fact they'd have every reason to want it fixed.
Admin
Firstly Sales tax is a local tax, not federal. Secondly, if you read it, the tax was being calculated at a higher rate than required. So it was the customer being scammed out of their money, not the local government, they got a little extra.
Now are you mad?
Admin
It's funny. I was once told by an employer to not get "too emotionally attached" to any of the code I wrote in case we decided to throw it out. Yet, the same management pricks will so desperately cling to whatever asinine things they sunk money into even if a new solution wouldn't cost them anything to replace.
Admin
Not necessarily, it depends on the reporting. It is possible that they got a report of "sales tax collected" that simply added up the amounts from each receipt rather than recalculating it off total sales. This would give the local government the extra.
As for wanting to keep it, they could have other reasons. Note that they were not changing any of the back end systems. somewhere back there could be the system that recalculated or did something else with this data and changing that systems inputs could have an affect on overall reporting.
The programmers could be saved from wrong doing due to this one piece. They can claim that for all they knew the rest of the system adjusted for it so these bugs were probably needed and that is why the client asked for them.
Admin
This "code" is not necessarily fraudulent or illegal. Having owned and run a small business, I learned that what matters to the tax man is that you remit to them what you collected. That is the number one "law" of retail sales tax. If you collect your taxes based on line items, then you must remit your taxes collected based on line items. I'm under the impression this business had always sent their taxes to the tax man that way - and if they changed for some reason - they most likely would have undergone extra auditing and scrutiny. The software should have been developed as asked for - it was not faulty - it was their accounting practice.
In the end your taxes collected as a business NEVER equal the exact "percent" of your total sales for the taxation period (usually monthly).
What you will see is collecting per line item or per total transaction, will always lead to a different amount of sales collected based on the number of items each individual transaction consisted of. Which is "more correct"? That's up to your accountant's interpretation. All the tax man cares is you send all of it to them.
I charged in my store sales tax "per sale" as is customary. Some months I sold larger items to just a few customers - so my tax rounding errors were "small" but still existed. 1000 customers in a month, each sale before tax $9.99. Tax collected each time - 60c - taxes collected $600 on $9990 in sales. $0.60 error from rounding that month. Other months I sold many smaller items to many customers - my tax rounding errors were large. 10000 customers at $0.99. Tax collected per sale 6c - total collected $600, on total sales of $9900. Error: $6.
Just remit all the taxes to the government that you collected and you're well within the law. Some day they may come to you, audit your books, and say "could you change this method - your rounding errors are larger than acceptable using this method". On the other hand, they may look at your books, see "total sales $9900, taxes collected $600, error is within 1%, ignore".
Admin
It's not a code WTF, it's a business WTF.
Admin
Admin
Of course, after experiencing so many bad user interfaces, people have been trained, most of them without realizing it, to expect significant difficulty adjusting to a new or unknown version of any software.
Admin
Is it any wonder that Point of Sale and Piece of S**t use the same POS acronym?
Admin
Having managed the finances of a fairly large international business (albeit none of those nations were the US) I can say that you are right. Reading the article again, it looks like the developer misunderstood something. Per-line sales tax is not illegal in itself in any country I know of, nor is rounding rather arbitrarily as long as it's in good faith, or even out of indifference.
There may be specific laws put in place for the sake of the likes of Walmart who sell billions of items every year, but even they would not get a specifically harsh treatment over something like this, even if they did establish it was a deliberate attempt to score extra cash from round-off errors.
With a system that integrates the cash registers with bookkeeping, all the extra tax would be entered to the exact amount in an outgoing tax account anyway. In a very small business you might simply calculate sales tax from the sum of gross sales minus deductable purchases, in which case a systematic round-off error could amount to extra profit. But for a business that small it'd hardly pay for the extra ink needed to print sales tax next to every item.
Admin
You say this as though is justifies any amount of stupidity.
Admin
As a matter of fact, depending on the location, line-item tax computation may be the only reasonable approach. For example, a state may have no tax of food items, a basic tax on general merchandise, and a higher sales tax on alcohol.
The software could, of course, maintain per-category subtotals, for the purpose of tax computation, but that can become a real pain to maintain if the number of categories is large. It can make the code really hard to maintain if the number of categories must be periodically reconfigured (as they do, since tax laws change all the time, and vary greatly from state to state.)
Admin
wow, this has the OOXML-smell
Admin
So they spent scads of money to have somebody else redevelop software they already owned?
Wouldn't it have made more sense to buy out the bankrupt company, claim the original source code as asset, and sell the rest off at auction?
Admin
Admin
Admin
Admin
What Chris and anonymouse said.
I'm in the POS industry, and our totalling code? Done the way the accountants demand it be done.
Those who've never dealt with accountants and tax laws and the rest are typically not aware that what the accountants (both at the business and at the government agencies collecting taxes) Don't Do Things The Way You'd Assume.
As long as you have a plausible good-faith attempt at implementing the rules, you should stay out of legal trouble - the real headache is satisfying the customer's accountant.
Especially when the accountants of different customers have different ideas of what "gross" should mean in your reports...
Admin
i beat off while writing code because I love it so much
Admin
Almost like SAMBA, they strive for bug for bug compatibility with Windows.
Admin
That miscalculated tax can be pretty profitable if your end-of-day report is calculating the tax correctly. Uncle Sam never has to know...
is that "the final touches" or "the final touchés"?
Admin
Oh, this sounds very familiar. It's a lot like a WTF I have been meaning to submit. I spent a few months writing a Windows application that was to replace an AS/400 application that store personnel accessed over a terminal. I had the application completely working, but when I presented it to management, though found it unacceptable. They made me change it so that it was full screen, made me change the colors to green on black to mimic the AS/400 terminal, made me remove all the window decoration, made me hide the mouse and made me change the keypresses to mimic the AS/400 terminal.
Admin
A while back I was reading an article about businesses that charge sales tax on items that are non-taxable, simply due to confusion over what is and isn't taxable (things like, if you buy a dozen donuts it's non-taxable groceries, but if you buy a single donut it's taxable convenience food).
According to the the government official's response, in Washington State it is not illegal for a business to collect more sales tax than is required by law - as long as the money actually gets passed on to the State. Of course, not collecting enough tax is another matter entirely...
CAPTCHA: tastey (mmm, donuts...)
Admin
That sounds like Emacs to me. They should have just given that to the customer and let him build the system himself. It would've had all the bugs he'll ever need.
Admin
Technically, the stores have the option of paying the sales tax or passing it on to the customer (at least in California the option exist). If you owned a business, which would you choose?
Admin
So my dad the CPA answered the question for me of whether this is a WTF or not. In the interest of not ruining his explanation, I'll reproduce his email here:
Admin
i worked for a security system company that did the exact same thing
we moved to .net mssql environment but it had to look like dos and would need to still interface with the old clipper inventory
nice going backward
Admin
I would say that, in this case, success is worse than failure.
Admin
I hate to say that I've been involved in one of these types of scenarios before, while porting a European title from set-top boxes to PCs and Macs back in the 1990's. We took all the algorithms supplied to us, and found a bug in the determination of a Julian date, and provided a fix for the functionality that used the date.
Once in acceptance testing, the customer insisted that we unfix our fix to exactly match the bug in the set-top implementation. We argued that the other code was incorrect, but they were adamant. It didn't matter one way or the other, because the application was...well, a fortune-telling program [make up your own joke]...and nobody running the PC or Mac version would be comparing the results to the set-top box version, but nooooo. So, we put the bad code back in, grumbling the whole time.
Needless to say, once launched, the product was a huge success, selling more copies than any other PC or Mac product released up until that time in Europe. To this day we're still annoyed by the idea that we had to release a bug because some other developer couldn't determine how to calculate a Julian date correctly--and it was the most successful product of its kind in that era!
(The specific platform from which we were porting didn't have any libraries for it. The code was in a very odd language that didn't match parentheses. It's not like the poor guy had a standard library of date and time functions to use. We did...and we weren't allowed to use them!)
Admin
I don't get it. How is it NOT a bug that the software doesn't do what the user wants? So they want some specific way of calculating tax. If the software doesn't calculate it that way, it's a BUG. The "proper" way of computing tax doesn't really enter into the question. They wanted behavior X, and they didn't get it. That's a bug.
Although it sounds like this software is riddled with stupidities, I think calling them "bugs" is a stretch. Dumb requirements but requirements nonetheless.
Admin
Uncle Sam does not collect sales tax! Cousin New Jersey and crazy Aunt California do. Nephew Delaware doesn't so that people will shop there.
Most U.S. states have "Taxation" or "Weights & Measures" departments to make sure measurements on cash registers are correct. Sales taxes are much more closely monitored than the federal income tax.
Admin
To the best of my knowledge, sales taxes are the domain of states, counties, and cities.
Several years ago, I called the Texas Comptroller's Office to ask them some questions about sales taxes. One of my questions was what happens if the retailer collects too much?
The answer was that the state of Texas doesn't care as long as the retailer remits to the state ALL of the sales taxes collected. If the retailer collects more taxes than they remit to the state, that is tax fraud.
I assume other states have similar laws even though they may differ on exactly what items are taxable.
Admin
Sorry, but you're absolutely wrong. A well designed user interface is one which achieves its goals. The amount of training required may or may not matter with respect to the goals.
In some situations, it's acceptable to have a learning curve to the UI because efficiency is more important to "learnability". That's usually the case in something like a data entry app whereby after a brief training period, the user can enter data quickly. This is as opposed to using a wizard to walk the user through whereby it'd be easier to use the first time, but cumbersome once the user knows what he's doing. Another example would be the use of a graphical calendar users can click on to select a date versus a text box for them to enter one in. In the aforementioned data entry app, it's more efficient to enter the date in a text box than to have to click on a graphical calendar. Even though the calendar is easier to use for the first time because it presents the user with the options, the text box is more efficient for heavier usage and therefor a better control to use for this given need.
Another situation where "learnability" is not the most important thing would be military hardware. With military hardware, it's expected that during downtime soldiers can train to use the hardware. Also, ease of use is not the most important factor. Efficiency and effectiveness (2 different things) are more important. In the use situations for that kind of hardware, a soldier's life depends on the efficiency and effectiveness of the UI. He can train to interact with the UI with a blindfold on during downtime. But during armed conflict, "it has to work".
Contrast that to a situation where "learnability" is the most important factor, even above efficiency. One example would be a kiosk at an airport to pick up tickets. In that situation, the ability to use the interface without prior training is more important than its efficiency. So what if the user has to click a few extra times? So long as he can use the interface the first time he sees it, then it's a well designed UI. He may never again use that interface. Make it easy to use regardless of any additional steps needed.
Here's another use situation. Hotel room keycards. In that situation, most users will be using the keycard for the first time. Does the strip go in on the left or right? Does it matter if the card's up or down? Do you have to push it in and immediately pull it out? Does it matter? In that situation learnability is the most important factor. However, for a home based keycard system, users would be more tolerant of having to learn exactly which way the card went into the slot because of repeated use. It'd still be important, but less so.
User interaction design is one of my skill sets. It's amazing how much more complicated it is than I ever thought. Statements like yours are made by people ignorant of UI design. That's not a bad thing, which is why I'm trying to correct you.
Admin
Emacs doesn't meet the requirements, I'm afraid. It has just as much touch-screen capability as yer average browser, for example (ie none); it lacks old-style vi obscurity for screen navigation -- I think you'll find that cursor keys, up-page and down-page, and back-space all work handily out of the box -- and, most important of all, it is not a Point Of Sale application. Strange, that. Stallman obviously forgot a critical part of functionality for a text editor. (Which is probably why he missed the graphics and the cashier-friendly reminders, the naughty man.)
You could probably configure it to be one, though.
What's the matter? Nanny had an embarrassing elisp that she transmitted to you when you were growing up?
Admin
Apparently we're not in 1776 any more, Toto...
Admin
Well, the rounding up of the value could be perceived as such. Rounding should only really occur on the total. In fact, adding tax to the individual items rather than the total makes sense because there can be items that are non-taxable.
Admin
If the Hall of Shame's sibling document tree, the User Interface Hall of Fame, were still taking submissions, I'd nominate the Sheetz Made-To-Order customer touchscreen terminals. Sheetz tends to do business is areas with rather low levels of education, and yet I've never seen anyone have any trouble placing an order. I was blown away the first time I used a terminal. It's completely intuitive and it's very efficient. (The food isn't very healthy, though.)
Admin
I partially agree, but the blame is not on the developers but on the guys who created the requirement spec for the customer.
I recall a similar situation in a company I worked for in Germany, there was this 1,500 page requirement spec for a project, very structured describing all the screens and the functionality but when it was delivered the fundamental parts had to be programmed on the spot, cause nobody had really cared about walking through the solution with the customer. It was "fun" going there expecting to stay over the weekend to install and then instead spend the next six weeks programming 15 hours a day non-stop to get in all the functionality - 10 developers on site.
Admin
Admin
Admin
I suppose it also warms your little heart to see all of the customers being scammed out of money as well?
Admin
Admin
You just reminded me of the summer I worked at Kroger, and the old lady who was using a gift card (and had evidently never used a credit card before either). She thought the card reader had some kind of optical scanner that read the printed numbers and tried to argue with me when I told her it was trying to read the magnetic strip.
I don't fault her for it though. She's old. Those machines weren't the least user friendly terminals I've seen. Most people could look at the icon showing which way to hold the card, but the designers didn't take into account the old lady vision factor.
Some things that would help avoid card confusion:
The point I'm making here is that there's always room for UI improvements, and that those improvements can be made in such a way that they help the people who need them, without nagging the people who don't. More designers need to realize that so I don't have to click "yes, I want to close this window" 50 billion times when I'm rebooting my PC...
Admin
wrong. the FED gets all of it.
Fact: the FED is an entirely private entity that steals money from people
Admin
$5 says this is Rite Aid. Worst.POS.System.Ever.
Admin
The failure here had nothing to do with code.
The failure had to do with either a missing product manager or a product manager that should be fired. Simply put, the customer had a very clear vision of what the product should do. It is the product manager's job to come up with a spec that gets approved by the customer up front so the first cut of software is in fact what the customer wants. A good spec would include bug compatibility issues.
The customer's position is completely reasonable. There is presumably a large ecosystem of integrated working infrastructure where hundreds if not thousands of people are already trained up on it. The cost of switching over to an entirely new system would be huge. Unless the CIO can quantify the business value to making the investment (e.g., we can reduce inventory levels and get our books filed with the SEC in less than half the time with a new system) there is no reason the business should make the investment. Plain and simple.
Admin
They probably forgot to implement the Pentium FDIV bug properly.
Admin
Several years back I worked for a company that made POS systems for Dry Cleaners, and our software was modeled on an old cash register that most of them used. Giving them something familiar was better than giving them something completely new. Ok, we didn't go to these extremes but I see why the retailer wanted it that way.
Incidentally, in a homage to yesterday's WTF, it was written in Clipper.
Admin
Isn't this basically the same process by which new versions of Microsoft Windows were developed before Vista?
Captcha: bathe. Eh, maybe tomorrow.
Admin
Well put, sxpert! The IRS [unofficial] slogan: "We've got what it takes to take what you've got"