This has to be one of the weirdest little programs I've ever worked with...
Back in 2003 I built a database to track our liquor inventories at work. It's fairly simple in that it has a table of product details like name, price, size, cost, etc... and a table that records my inventory counts. We used a little Palm Pilot with a built in Symbol scanner to collect the scan date, UPC code and quantity on hand. As we estimate our partial bottles that sit on the bar, we record decimal quantities on hand. (i.e. 2.1 bottles.)
This has worked really well for the last few years, but as with all technology, it wears out. While the database is fine, the Palm Pilot is another matter. The screen calibration went so far off and despite several resets I couldn't fix it, rendering it useless. The bad news, of course, is that the unit we used has been discontinued for about 2 years, and my last replacement unit... well... it's now in the trash.
Fortunately I already had a new device on hand to use. We'd installed a new system in another department last year that came with a handheld ruggedized scanner. Very nice little unit made by Unitech (HT-630). We were so impressed that we bought a second one. One reason was that we now have a backup unit, but the other is that the vendor (whom I know fairly well) convinced me that I could use this as a replacement for my aging Palm units. "Oh yeah," he told me, "it's fully programmable. You'll have no problem knocking up a little program for it. There's a whole programming environment, you build the job, upload it and you're good to go. It won't be a problem for you."
I love that people have that much faith in me sometimes... then there's other times where I want to phone them up and...
At any rate, I've been meaning to get around to programming this new unit, but just haven't been able to make it a priority. But since our little Palm Pilot blew up, that kind of forced the issue. And naturally it had to happen two days before quarter end. Great. So last Thursday/Friday I spent time trying to get this thing working in time for them to count inventory on Saturday. Nothing like a little pressure!
The odd thing is that this unit is programmed by building a flowchart. I've never seen the like before. To me flowcharts are used for documenting how the program works, not telling the program how to work. Very odd. The shot below is from the program I released on Friday to count inventory. (Yeah... I DID do it, but I wouldn't say it wasn't a problem!)
This was a real trip to work with. Ever seen a flowchart that is allowed to go multiple directions at once? I haven't. To me flowcharts have a decision point between every directional choice, but this little program actually flows data along one arrow and the input screens along another one.
And well creating the flowchart is all good, you then have to configure every option of every node in the chart. You can't copy an existing node that is setup correctly either... each option of each box has to be configured. Each link, each input, everything. This is just one of at least 14 screens to configure. Each line you see (incoming and outgoing) increases that count by 1, (image below has 20 screens to do) so it's very tedious:
It took me about 1½ days to built this program. I spent a ton of time spinning my wheels trying to figure out how to make a lookup file work, then trying to figure out how to write the data to the text file, then trying to figure out how to upload the program to the unit, and then I thought I had it. Then I reviewed the collection file and figure out that it was submitting a full record every time a single piece was captured. So I'd get four records for every UPC code, one with the correct quantity, three with the prior... arrggh!
I also capture the count date and month end date. I was really happy to see that you could use a formula too, so I figured that I could use a formula to convert the count date to the month end date. I quickly jumped into the formula screen... and after staring at that for about 4 seconds I clicked the Help button:
Seriously? "Write pieces of C code"? Try web searching for some help there... even when I did find something, I couldn't figure out how to make any sense of it!
In Excel this would be easy.... =If(Day(CountDate)<15,Eomonth(CountDate,-1),EOMonth(CountDate,0))
If anyone has any idea how to write that in C code, I'd be really grateful. There is no manual with this software and the "Help" files are about as useful as... well... they're not. I ended up ignoring the formula and elected to capture the count date twice. I just have to edit the text file and replace one of them with the month end date right now, and I'm good to go.
At any rate, I DID get the program working in time, and deployed it out there. The staff are ecstatic as it is much simpler to use than the last one. Yay, it's time to celebrate!
Almost.
Today I was trying to import the text file into the existing table in Access. Access is causing me a hell of a hassle as it wants to populate the AutoNumber index field with my text file data. I don't get that. It was never an issue before. I even put headers in my data fields, but no luck. I may have to resort to VBA to use a SQL insert statement in a loop to get this licked.
Worse though is that I messed something up. All of the decimal counts have been truncated to whole numbers, which makes my count file useless. I HATE having to deploy new technology in a hurry without proper testing. Our only recourse now is to estimate our inventory this month end and deal with fixing the technology issue for next month end.
At any rate, this has been an interesting learning experience. Programming C using flowcharts... it's just plain weird.
