I've been pretending that PTAEO is five variables.

And that is true, from the perspective of the user.

But in START, there are two more arguments that are hidden from the user.

Requirements to fix up the problems with PTAEO in light of March meeting with Igor

Requirement 74 - modify PTAEO to send EID as current SYSDATE

Previously it was hardcoded as a date in 2010. Did an analysis that confirmed that EID is the current Oracle SYSDATE. Need to set this on the server side and send it through to the SOAP web service.

Requirement 75 - modify PTAEO to send Transaction Type, defined by each Catalog Item

Previously it was hardcoded as V on the server side. Need to define this on the client side in the three PTAEO variable sets. And need to set each catalog item to provide a value unique to that catalog item.

Results from meeting with Igor B. Mar. 22, 2013

I met with Igor and we dug through how PTAEO works. We discovered two things I didn't know before

EID is just set to current date

We checked, and EID is just the Oracle SYSDATE. So if I can format current date properly, I can pass that through on the server side over to the SOAP process.

The value passed for transaction type is definitely varying, and dependent upon the catalog item

For example, the ethernet request is of type 'U', for usage. This means that I definitely have to modify my PTAEO validator to have the transaction type defined on the catalog item itself.

Mail from mid March 2013

I sent mail to Barbara Manville about this. Waiting to hear back.

== begin mail

I've built a PTAEO validator that works with ServiceNow and webmethods,
and passes values to the a in HOP. In this manner, I have replicated
functionality in SN that is presently in START.

However, I think I have a shortcoming in my design that will bite me later.

The script / validator accepts seven arguments.

The first five are obvious and presented to the user as the five pieces of
PTAEO.

The last two are subtle and hidden from the user.

eid is the Expenditure Item Date. I assume that START is just passing
todays system date to the backend.

1) can somebody pry into the backend guts of START and confirm or deny my
assumption?

transaction type is one of the set:
l - labor (time and materials?)
v - vendor (probably what many of the items are)
u - usage (apparently a catchall for anything that doesn't fit nicely into
the first two)

I have a hunch that these values are hard coded into the back of START
catalog items, as they aren't presented as part of the UI.

My actual question:

2) Do we vary the transaction type with each START item? If so, I think I
will need somebody to walk through the as-is START and get me the
collection of transaction types that correspond to the items (of course we
can constrain this analysis to the set of requests that are actually
moving forward into SN).

3) I don't know whether Barbara has the right level of access to see that
layer of the START stack, or whether I should be making this request to
somebody else.