This article outlines any Critical or Hot Fixes made to the system.
Multiple eoMobile Applications Running
This is only an issue if running a version of eoMobile that is from the 9.5.22.xx branch.
The handheld tracks user data by keeping all information in main memory, and by backing it up to the disk, in case the application is closed or power is lost. When the system backs up the data, it puts it in files titled something like “upload01.txt” in the program data directory. Upon loading the application, it will read “upload01.txt” right away, and see all the transactions that were performed and all the things the user did with it while working (such as password attempts).
When the user syncs the handheld with an “upload only”, the data gets sent to the web service. Which sends each clump of data with a unique identifier created the last time the user did a successful upload. This means that the web service does not import the same data twice.
Now we know enough to talk about what’s gone wrong. Here’s the sequence of events that we’ve seen happening.
The issue is that the user starts the handheld and does some work. The system creates an “upload01.txt," and gives it unique identifier (ex. 123456789). In the middle of the user's work, they restart the application due to whatever reason (i.e. the handheld ran out of charge, and she rebooted it).
However, after clicking the “eoMobileCF” icon, while it’s loading, the user clicks it again accidentally! Now, two copies of the application will start. The first one starts, and she starts working on it and doing her usual route. Meanwhile, the second one starts up in the background. Both of these copies start out looking at the data currently in the system (unique ID 123456789).
Our user now makes some more orders using copy A. When finished, they sync. Copy A sends all the orders since the user first started (ID 123456789.) Those orders go to the web service fine, and nothing is wrong. The user then closes copy A, and goes home for the day.
The next day, the user picks up their handheld, but eoStar is already running; it’s running copy B. Remember, when copy B last left off, it only had the user's first pre-sell orders that they made before the restart. So those are the only orders copy B knows about! Now, the user makes some more orders and then performs a full sync. Copy B thinks that it has two bunches of orders, with ID 123456789. However, when those orders get sent to the web service, it’s already seen number 123456789, so none of them get posted. Half of them were duplicated from the earlier sync, so that’s OK. But half of them were brand new orders that will never get in now.
This bug was caused because the user was running two copies of the application both at once, accidentally. To fix it, we’d prevent the user from starting more than one copy. So when the application starts, we talk to Windows Mobile, and mark a special token in the OS signifying that eoStar is running. If they try to start a second one, it’ll see that our token is already in use, and we can gracefully do something about it.
Here is the expected behavior once the hot fix is installed:
- If a person clicks to start the app while the app is already running, it will just go back to the first copy.
- If a person clicks to start the app while the app is initially loading, it will simply wait for the first one to start.
On another note, because two sets of the data files where maintained in memory this might also be the reason why users have experience memory issues that required frequent warm boots throughout the day.
Rutherford published the hot fix to the Mobile Device Manager on August 6, 2009. This change is located in the 9.05.23.XX version of the branch. The change of the 3rd digit to a 23 ensures that the mobile device manager will recognize that this is an upgrade to the previous version. Additionally, there have been significant changes to address the printing issues that were experienced on the Zebra and O’Neill printers.
IDOR Fix (2009)
In June of 2009, an issue was resolved that caused a discrepancy between the schedules and RL-26 (Liquor Revenue Returns) when the distributor had returns to the supplier. The RL-26 displayed the correct numbers, so that the taxes payed to the state of Illinois were correct, but the schedules did not display any supplier returns.
To handle this issue, the distributor should submit amended returns. Additionally, now when a negative purchase is created to reverse an incorrect purchase, it will be reported to the state on Schedule C. The Net of Schedule A and Schedule C will be correct; however, seeing returns for the first time may be a surprise.
Due to this issue and IDOR increasing the excise tax rates starting September 1st, 2009; Illinois customers should upgrade to eoStar 2009.
IDOR/Clockwork Gallonage (7/19/2011)
Recently we discovered an issue with the IDOR query to export sales numbers to Clockwork Gallonage.
The issue lies in the restrictions of the cutoff date. It was set for midnight, so that orders delivered after 12 AM on the end of the month (such as 6/30/2011), would not have been returned in the query.
This issue has been addressed today (July 18, 2011), and you should be getting contacted soon to receive the Hot Fix. Please be sure to verify your sales prior to filing your taxes by printing an ION sales report. Note: the Clockwork Gallonage program allows you to add or change dates prior to filing the return.