Payment Editor

I snapped. Heh.

It was about time I grew tired of all the editing I have to do with all the mistakes in posting payments. Every time Agnes calls me to adjust batches of O.R. numbers, I have had to:

1. Load up the SQL front end.
2. Open my database of commands.
3. Open the commands table.
4. Select the second-to-last record for the template.
5. Copy the template's starting O.R.# to the clipboard.
6. Ask Agnes what the starting O.R.# to edit is.
7. Search and replace.
8. Copy the template's ending O.R.# to the clipboard.
9. Ask Agnes what the ending O.R.# to edit is.
10. Search and replace.
11. Copy the template's date of payment to the clipboard.
12. Ask Agnes what the posting date to edit is.
13. Search and replace.
14. Ask Agnes what to edit (teller_id, payment_date, O.R.#'s)
15. If O.R.#'s, switch to the command prompt or load one up.
16. Calculate the difference between correct and wrong starting O.R.#'s.
17. Search and replace.
18. Execute appropriate commands.

Now, with editpay.bat, I have compressed these steps into:

1. Editpay , , ,
2. Execute appropriate commands.

Kewl!!!

Floridablanca server disk full

Last night at around 9pm, Rico texted me and told me that he's getting errors.

I told them to go home because the problem had a simple solution: erase binary logs... and so I did, this morning. I went to the office before 7am and quickly solved the problem.

I also included Michelle to the sudoers, for good measure. So in the future, I can just instruct her over the phone...

Uploading meter reading data

Last week, I modified the MR Uploading module to include a check for the area's existence before the uploading proper started. In my blog entry, I prayed that I didn't introduce a bug "this time" but, guess what... (altogether now...) I DID!!! :-(

My latest quick fix failed to take Power Bills into consideration. Since Power Bills were read not by area but by reading day, the uploading process stops dead on its tracks at the area check.

I fixed it immediately.

Dvorak keyboard layout

There's been a sudden surge of the Dvorak keyboard layout in the plug mailing list lately, and it piqued my curiosity.

Now I switch to Dvorak when I can take time typing. Like now.

I'm still far from my qwerty speed though.

New thinkpad joins domain

I got my new company-issued Lenovo Thinkpad X61 7676A14 last Friday! Woot!

It's pre-loaded with "Vuisit-a" Vista Business, even though the sticker on the keyboard says Vista Basic. Nice, huh. Another pleasant surprise is that it's a Centrino Pro (I thought it was Centrino Duo only, not knowing of the existence of the Pro)! Centrino Pro is targeted at businesses. It's essentially the new Centrino Duo platform with an extra Intel Active Management chip. What this chip does is allow remote management and enhanced security features, even without an operating system.

Today I got the first chance to make it a domain member, but I kept getting "incorrect password" errors, despite disabling the usual "requiresign" etc... features. So I googled and found, among other links, this link.


- Click Start
- Click Control Panel
- Click System and Maintenance
- Click Administrative Tools
- Double-Click Local Security Policy
- In the left pane, click the triangle next to Local Policy
- In the left pane, click Security Options
- In the right pane near the bottom, double-click "Network security: LAN
manager authentication level"
- Click the drop-down box, and click "Send LM & NTLM - use NTLMv2 session
security if negotiated"
- Click OK
- Restart the computer


But since I was already in gpedit.msc (my usual approach), I looked for it in Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> Network Security: LAN Manager authentication level, and selected the same setting as above excerpt.

Voila! Instant access to the network! Next project is to replace our wireless access points with 802.11N... Woot!!!

BCMS: Bug Fix

My additional code for automatically Unvalidating zero and negative consumptions bit me.

I should've never touched the VALIDATED field if the computed consumption is negative (zero is now acceptable as valid), so I corrected it not to touch the VALIDATED field if the computed consumption is NOT negative. Otherwise, UNVALIDATE it.

I also corrected the Rover UPLOAD module to check for a matching area_id where searching for the account_no_id of the current consumer whose reading is being uploaded. I did this because some old account numbers in FB were equivalent to SF old account numbers when the hyphens are removed, and this screws up the upload process for some accounts.

I hope I didn't introduce new bugs this time.

BCMS: Data integrity fix

DPP and ELP approached me and reported that there was a NEGATIVE BILL last month. ELP was very quick to point out that i should put in code that checks for negative consumptions during bill computation.

My first reaction was unfavorable; I told him the flow of the system should be sufficient in preventing such problems. After some more thought, though, I realized that it's not a bad idea to do that as a "last line of defense" against this particular problem.

I then proceeded to search for bugs. During this search, I found out that the account is a mother meter and quickly realized that it was already PreVALIDATED by the program and retained its validation status even after the encoder has subtracted the sub-meters' consumptions. So I also added code that re-validates the reading after said input.