|
We are also a private company, for which SOX does not now apply.However, I have been studying SOX because a real serious implication is that if the owners do certain things, like bringing in an investor from another nation, we could become subject to SOX, which is retroactive.
I use back door solutions on average, a dozen times a week.About once a month I figure out another back door solution to a problem we been having that I had not previously figured out how to fix.
Every time I do so, my back door action is authorized by the people in charge of the data where I am doing the back door actions. Although I suspect some of my co-workers are unaware of the fact that I am implementing their wishes using back door methods.
Years ago, back door actions were once in a blue moon.The actual back door action probably took me less than an hour to implement. The unexpected mess on the system cost me several hours, and greatly inconvenienced people who depend on the stuff that runs thru GO CMDSCDE which amounts to dozens of jobs a day.
I told them that I was happy to know that this kind of fix was in fact doable, but next time I will strive to find a different way to do it.
Extending due date was something I had not thought of, but would require the setup of terms for that, and applying them to the shipped order. I am authorized to do back door fixes. I am not authorized to setup other terms and place them on customer orders. But thanks for the suggestion. I will ask about that with the expectation of getting such authorization to include in my bag of magic tricks.
While there are also solutions within the system for most scenarios where I doing back door stuff, we are on tech support contracts, where if we not call tech support, we not have to pay them anything, which means management approval to call tech support, which means if we can figure out a back door way to fix some problem, that gets used instead, which means the company is experiencing a rapid growth in using back door fixes, like business as usual.
We know about issuing credits and re-billing. That requires more work that the regular personnel are not enthusiastic about doing, when there is a perfectly good back door guru available.
The business documents appeared the way the people requested them to appear, both at the customer site and at our site.
The customer wanted the invoicing and receivables to reflect reality as if the shipment was made Feb-3. The "paperwork" on the invoicing and receivables was the way desired by our personnel, and personnel at the customer site, according to e-mail back and forth with them.
Our shipping documents and history showed that the inventory actually walked out of the building Jan-20. No fakery was done with tha actual shipment.
There was e-mail between relevant personnel identifying the error and clarifying what exactly they wanted done about it.
I do the billing in the evenings after everyone off the system. My first steps in billing are * Check to see if the shipping people are done for the day.* Check 3 different ways messages & e-mail are sent to me from personnel in shipping and customer service requesting back door fixes to the data for billing from today's shipments
The attitude by my co-workers, who are in charge of the data, is that if an error in shipping is allowed to stand in billing, then THAT is a false document. e.g. shipping tells BPCS that we shipped 1000 parts at a price of 2.25 each, when in fact only 100 parts went out, which should have been priced at 4.25, then the billing invoice should reflect what was actually sent the customer, at the price at which it should have been sent, because they shipped against the wrong customer order line, where quantity discounts are based on quantity involved.
I saw that what had been shipped was a Forecast, not a Real Order.I billed everything except that shipment, delaying its billing to another nite, and listed several approaches what I was aware of that could be done, mainly back door solutions. The requested corrected billing receivables e-paperwork was a new scenario, calling for a new version of back door manipulations.
Actually I have found a back door to recover from a 5250 session blow up that I think is quite cool. 1. Vary off the session that blew up, and vary off session on a device that is A-Ok. 2. Use WRKCFGSTS to switch the device identifications, so what was device-A is now device-B and what was device-B is now device-A
3. Vary the devices back on again4. Have the user, who was at the busted device, sign back onto the system using the other device, and when the AS/400 asks if you want to try to recover to a busted session, take the Yes option. 5. The user is now in the job that was on the busted device, except they in the same job on the alternate device. I advise them to get to a break point then menu, then restart whatever program, so as to minimize any extraneous glitches.
This works at the AS/400 level, and at the application level. Usually.
Al Mac wrote: > I usually do the hour change right after a backup. > > I recently had a situation where a shipment was made to a customer a week > early in error, and the customer agreed to keep the shipment, provided the > billing was as if it got shipped when it was supposed to. Why not just ... -- issue a credit without inventory,and re-bill without inventory on the desired date? -- OR -- -- extend the due date on the original invoice a week? > I was able to get the system to do this, by several manipulations, > including advancing the system date to when the shipment should have been > made, then having the billing run, so the "corrected" dates into when > receivables due and general ledger etc. (fortunately inside the same fiscal > period), then putting the system date back to what it should be. This is craziness. Why didn't you just change the dates (using DBU/DFU) of the billing and inventory transactions? Given that it was in the same period, it should have been fine. > The users quite happy ... which is the case any time Al Mac does some > "magic" to make data come out "right" without people having to do any real > work to accomplish the goals. It is one thing to work "magic" when something breaks, a program blows up or a 5250 session disconnects or hangs up. You are fixing a system issue, and there really is no other way. But using the back door tools to correct user errors is not wise, since the system has tools/process to back out transactions and execute them properly. When I started here I had a programmer who would do that kind of thing; correcting user errors using the back door so they were hidden. The users loved him, but it drove me crazy. I put a stop to it unless there was a system problem. It was amazing how quickly the careless errors stopped happening, and I got back a couple of hours a week for that programmer. How many hours did you spend doing this and cleaning up the mess afterward. I bet it was in excess of 12 hours, which was far longer than it would have taken the users to credit and re-bill. > I would not be surprised if my action violated SOX. Almost certainly it violated SOX; the question is if you broke any other laws. You have falsified business documents. What if the customer refuses to pay the bill? You can't prove that you shipped on the real shipment date, and you can't prove that they received the shipment that you created, because they didn't. One of our jobs is to guard the integrity of the system. If we sneak around the system and make it lie, then by implication it can't be trusted. That is not a good thing. -- Tom Jedrzejewicz tomjedrz@xxxxxxxxx -- This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/midrange-l or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
- Al Macintyre http://en.wikipedia.org/wiki/User:AlMac http://www.ryze.com/go/Al9Mac BPCS/400 Computer Janitor ... see http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
