As a followup action item from the 4/2 meeting of the billing working group, interested parties got together to push along the idea of a slightly-customized-for-CSS version of the TNSC billing system.
--------
4/9/2010 at 10 in N42-203 from about 10:20 to 11:00
Attending: Jana, Rob, Mark, Anna, Chris
Topic: work on Product listing for a CSS Billing System based on TNSC Billing System. 1.) Earlier in the week, Jana mocked up an Oracle Forms version of the ICE-9 product creation screen, so we don’t need direct access to the ICE-9 application (which is TN3270 and has many TNSC peculiarities we are best shielded from).
- Oracle Forms screen is still Oracle 8 and Windows-only.
- We want to ride lightly along on the existing system and not ask for any large changes at this point, until the future of the whole environment is more clearly established (and that has lots of OIS dependencies).
2.) The new “Product” screen defines products based on these fields:
a. Product Code – 15 char string uniquely identifying this billable object
b. Product Description – extended text for the agent to understand what is. Client does not see this.
c. Type – 6 char code to help group related charge types
d. Rate – price per unit for this particular product code. You cannot separately change the rate at a later point.
e. Client GL acct – the cost object on the client side
f. Offset Cost Object – the cost object on the IS&T side
g. Offset GL acct – the GL account on the IS&T side
h. SAP Description – this is default text offered as what to enter into SAP – can be edited at the time of transaction.
3.) Practice example
a. We created a “SW-Repair” product,
type “SD-RC” for service desk repair center,
rate “60”, understanding the unit to be an hour of consulting.
Client GL was 420298 (or something like that, it was just a practice example),
offset CO was 1637520,
offset gl 801046 (Internal billings);
SAP Description was set to “IS&T Service Center “
b. We understand that the RT # can be entered into a separate field on the create-a-charge screen, and it passes through to the DTR in the reference document field _separately_ from the SAP Description. So we left that out of the SAP description field above. 4.) Try it with a sample SW Repair charge
a. There is a tension between the idea of a unit hour @ $60 – you have to calculate portions of units to get $70, say, as a total – and setting the units to just be dollars and bill for 60 of them, or 70 of them, or whatever the total wants to be. Chris would be likely to create Products with dollars as units. Jana didn’t disapprove of the notion, and OIS does this with some of their charges. It’s just not entirely elegant.
b. Chris wanted his SAP Description padded with the email address of the client, so the AO/FA would be able to see who the charge was initiated by, and who should have the receipt already J
c. There was discussion of adding a field to contain the username, to help ensure that it is filled in every time by each of potentially many agents. But that would be overspecifying how the transaction screen ought to be used, and violates the “ride lightly on the existing system” rule. So the SAP Description can be formatted with internal prompts like “username@mit,edu” for the customer service agent to react to, if its creator wants to go that way.
5.) Stumbling Blocks
a. SW/HW combined repair is a case where the current IS&T financial structure wants separate charges to two IS&T Cost Objects (with the same GL) from one client-facing charge. The current system cannot accommodate that use case. Chris would have to change his billing practices to do two separate charges (HW and SW) for the same ticket. He was okay with that. A “duplicate transaction” feature in the system makes it easy to avoid needless data entry. Not a show-stopper.
b. Training remarked on having some clients preferring to bill one or another of several GLs – would have to have different product codes for each variation. Don’t want to go too far down the path of branching variations that have to be individually maintained.
c. The issue of these charges going into Sean Nicholson’s report about TNSC transactions was resolved by Jana reminding us that she and Kelly create that spreadsheet, and can easily exclude certain types of charges (our types) from that report.
6.) End of Demo and Next Steps
a. We had to adjourn before Training got to create any Products. Anna Pope and Jana will meet next week (4/12-4/16) to put together a trial transaction involving one department / two clients / 7 classes each to see how it flies.
b. Need to share our work in this area with Anne and finance. What we are after is to make available what Eileen Kenney does in OIS, but in CSS, and only for those who choose to opt in.
c. I can imagine we need a protocol for reporting out each month on transactions done this way, for Quentin to have and Anne to see. Rob will check with Anne on all this.
-------
Rob Smyser, Sr Business Analyst
MIT Information Services & Technology
77 Massachusetts Ave #n42-240t, Cambridge MA 02139
617.253.1358 w
________________________________________________________________
NOTE: IS&T will *NEVER* request passwords or other personal information
via email. Messages requesting such information are fraudulent.
________________________________________________________________