Jaggaer - Banner Sync Series

12 Aug 2022 🔖 databases integration
💬 EN

Recently, I’ve had the opportunity to engage in reliability engineering, partnering with talented accountants and engineers in a higher education setting that uses:

1. Ellucian Banner as its system-of-truth ERP.
2. Jaggaer (formerly called SciQuest) as its system-of-convenience purchasing tool.
3. Ellucian Integration for eProcurement (IFEP) alongside Ellucian eInvoice Adapter to sync the two.

Integration difficulties between Banner and Jaggaer

There’s a lot of complexity to manage, and sometimes synchronization fails.

I call the ERP a “source of truth,” but in bookkeeping, there’s no such thing as a financial records ledger that doesn’t really matter. Perfect synchronization between systems is mandatory.

In this series, I plan to cover tricks to get Banner-Jaggaer integrations up and running as quickly as possible.

Posts In This Series

Strict separation of duties

Troubleshooting issues amongs Banner, Jaggaer, eProcurement, and eInvoice is tricky because a lot of people aren’t allowed to touch other people’s stuff.

Often times, IT engineers won’t be allowed to use Jaggaer except as an ordinary university staff member who needs to order paperclips.

• Pro: This helps limit the first tier of staff to investigate to actual bookkeepers if an accounting scandal such as embezzlement were to occur at the university.
• Con: It also limits engineers’ ability to debug sync issues, since they aren’t allowed to:
  • Check Jaggaer settings.
  • Update Jaggaer settings.
  • Enter data into Jaggaer.
  • View whether data entered into Banner appears in Jaggaer.
  • Read synchronization error messages in Jaggaer.
  • Comb through the history of requisitions, purchase orders, and invoices in Jaggaer logs.

Similarly, accountants aren’t allowed to inspect the server logs or firewall traffic around Banner, eProcurement, and eInvoice.

• Pro: This helps keep non-IT people from accidentally crashing sensitive servers.
• Con: It also leaves a gaping hole in accountants’ ability to trace a synchronization failure between Banner and Jaggaer (via eProcurement or eInvoice).
  • Synchronization error messages as displayed in the Jaggaer web portal don’t always explain what really went wrong in as plain of English as logs on eProcurement or eInvoice servers do, which makes synchronization feel very cryptic and vague to accountants.
  • It can be easy to throw one’s hands in the air in frustration, hope that “the IT people” will “know why syncing is down,” and hope for the best.

Interpersonal communication tips

Remember when you were a small child, and you speculated that if you operated the gas pedals and your friend stood on the driver’s seat and operated the steering wheel, together you could drive a car?

Now you get to do it – engineers operating the gas/brakes, and accountants operating the steering wheel.

Engineer responsibilities to accountants

Engineers need to put on their best customer-service smile and:

Say what you want

Shepherd accountants into providing Jaggaer IDs and timestamps and full transaction + error message histories if a ticket comes in that is vague.

Bird-dog tickets. Assume there’s always more detail an accountant could tell you, if you just ask.

Pick up the phone

Get over your reluctance to picking up the phone.

Schedule a screenshare conference-call with accountants who are power-users in Jaggaer and Banner.

Oftentimes, accountants are even more intimated by cryptic IT failures than you are by cryptic accounting jargon and workflows.

It’s easy for accountants to presume you’re busy performing wizardry when actually, you’re subconsiously procrastinating a ticket because it doesn’t include enough details to begin troubleshooting.

The accountant probably won’t get over their shyness to bother you until the synchronization failure is a fiscal emergency to the university.

So initiate synchronous conversation ASAP.

Record walkthroughs

Ask accountants if you may record screenshares, so that you can rewatch them later as you debug and formulate followup questions.

Differentiate normal from broken

Ask accountants to show you examples of “normal” versus “not normal,” walking through everything from end to end in both Jaggaer and Banner.

Define words explicitly

At any given moment, it’s common for accountants to context-switch between different implied meanings of similar-sounding (or identical) words without realizing they’re doing it, because they’re accustomed to working with colleagues who do similar work and can keep up subconsciously.

Jargon like “requisition,” “purchase order,” “invoice,” or “approval” can refer to (sometimes changing from one sentence to the next):

• a specific Jaggaer data-table
• a specific series of steps to perform in Jaggaer
• a specific Banner data-table
• a specific series of steps to perform in Banner
• a general-purpose bookkeeping concept
• something else

Collaboratively document tests

Accountants and bookkeepers are extremely detail-oriented and excellent at testing.

However, they probably don’t approach software end-to-end testing the way an IT person does (constantly jumping around contexts, trying to come up with tests that cover less functionality at once, more functionality at once, etc.).

When you think you have a test in place, schedule a screenshare conference-call and watch them test and ask them to tell you what they’re doing every single time they click a button. If they do something without telling you, slow them down and ask them to tell you what they’re doing now – even if they don’t think it’s what’s actually being tested.

Take notes (hopefully they’ll let you record the meeting).

Document what they do. e.g.

“Accountant buys $1 of paperclips in Jaggaer, hits save, waits 2 minutes for a purchase order number to show up in Jaggaer from Banner, then looks in BannerAdmin’s FPIPOHD screen to validate that the purchase order is on file in Banner and matches the Jaggaer data”.

Document the context of your needs in which they’re performing these actions, e.g.

“Did so after I restarted the eProcurement server, in light of no purchase orders having synced all morning when sync usually completes in 3 minutes.”

Document everything so thoroughly that if a replacement walked in from Neptune tomorrow and encountered the same problem, you could tell the Neptunian what you’d like them to do for you as a test. e.g.

“I rebooted the eProcurement server. Could you try buying $1 of paperclips in Jaggaer and making sure that the purchase order looks good in both Jaggaer’s ‘All Orders’ list and in BannerAdmin’s FPIPOHD screen? Also, if the failed purchase orders haven’t synced within 20 minutes, please go into Jaggaer and force them to re-sync to Banner and let me know if any of your forced re-syncs fail.”

Don’t make accountants guess what you want them to do; be explicit.

Accountant responsibilities to engineers

Accountants should be extremely sensitive to just how incredibly little engineers know about Jaggaer, and even about Banner, eProcurement, and eInvoice, despite being “IT wizards,” and:

Over-explain

Be ready to over-explain everything about your day-to-day use of Jaggaer and Banner like you’re working with someone fresh off a rocket ship from Mars.

• You know how your company has a help desk full of wizards who install software like Microsoft Excel onto your computer, even if they have no idea how to use Excel properly?
• When it comes to software that runs on servers instead of personal computers, system administrators have a similar skillset with software like Banner, eProcurement, or eInvoice.

• It’s literally their job to skilfully follow software installation instructions having no idea how the software works. And then install something else they’ll never use the next day, and the next, and the next.

  

Differentiate normal from broken

Not only do you have to explain the day-to-day work you were trying to do, and what’s wrong, like it’s to someone from Mars … but they also won’t know what “right” looks like.

Give a really specific show-and-tell of both “normal” and “broken.”

This almost certainly will require a screenshare conference-call.

If, within 2 hours of your ticket being assigned an engineer, if they haven’t put an appointment on your calendar, just put an “I’d love to show you what went wrong” appointment on theirs.

If possible, record the walkthrough so that the engineer can watch it a few times as they try to figure out what went wrong and figure out what followup questions to ask you.

Copy-paste AND screenshot

Always provide details in two forms: both in plaintext and as a screenshot.

• The engineer needs plaintext copy-pasted information so that they can Google things or search logs based on unique-looking pieces of text without having to hand-type it out of a screenshot.
• The engineer needs a screenshot of the place that you saw the thing you’ve copy-pasted. Then, when they want to ask you to try again, they can give you context about what they’d like you to examine on their behalf.

Expand hidden messages

If there’s “...” or a “more” link in some sort of screen that conceals information until you expand it, expand it before copying/pasting the information or taking screenshots.

The entire message is always important for troubleshooting.

Big wide screenshots

Don’t crop screenshots tightly. Include lots and lots of context.

(Of course, you can black out secrets.)

A too-tight screenshot may lead to these messages from an engineer:

1. “Try again.”

2. “I don’t see that error in my server logs.”

   

Screenshots with lots of context are more likely to get you engineer messages like these:

1. “What happens if you refresh the page and click ‘History’ again?”
2. “I see from your screenshot that the error message whose text you provided me was something you encountered in failed purchase order #12345’s history log and that it happened at around 12:34 PM. Could you show me a screenshot of a successful purchase order’s history log, for comparison?”

Include URLs

Copy & paste web-browser URLs alongside screenshots to clarify what the web page you were taking a screenshot of.

(Of course, feel free to over any secrets contained within the URL with something like “SECRET_INFO_WAS_HERE” before sending. That said, BannerAdmin URLs and Jaggaer URLs are pretty good about not having secrets in them.)

There’s never enough time

Always, always, always be really specific with timestamp histories and duration expectations.

Jaggaer ID numbers

Always, always, always be really specific with Jaggaer ID numbers.

Banner details

Always, always, always be really specific with Banner record identifiers.

Also be really specific about the Banner data-entry form names that you are using to enter or check for data when you do the day-to-day task that you’re having trouble with.

Want to be an engineer’s best friend in the whole wide world?

Here’s the most delightful kind of message an engineer can get from a Banner user:

“I opened BannerAdmin’s FPAPURR screen, clicked the 3 dots by ‘Purchase Order,’ which opened BannerAdmin FPIPOHD screen. Then I searched for the record with PO #987654321. I noticed its datestamp said January 15, 2020 in Banner, but the equivalent Jaggaer purchase order says says January 12, 2020 in Jaggaer. These dates should always match; I’ve never seen them not match before. According to the BannerAdmin page footer when I click on these data points in BannerAdmin FPIPOHD, the PO number lives in the back-end database at FPBPOHD.FPBPOHD_CODE and the date lives in the back-end database at FPBPOHD.FPBPOHD_PO_DATE.”

Here’s how you get that kind of information:

• Click into a field of BannerAdmin, as if you were going to type into it.
• In the narrow footer along the bottom of the BannerAdmin screen, to the right of “EDIT” or “READ” or “QUERY,” and after that to the right of the Record Count, but to the left of the Ellucian copyright message, highlight the information indicating the underlying database table and database field behind the form-field you’ve just clicked into, copy it to your clipboard, and paste it into your message to the engineer telling them that it’s the “back-end database location” of the information.
  • (You can also get it by clicking Tools -> Item Properties after clicking into a field; the engineer needs the Data Block and Physical Name values.)
• Specify the data-entry BannerAdmin form name that is actually shown up at the top of the BannerAdmin form, and/or that’s at the top of the lookup popup, when you’re doing this whole Tools -> Item Properties process.
• If different, also specify the data-entry BannerAdmin form name (e.g. FOAIDEN) that you first typed into the BannerAdmin home screen to begin the process of navigating to the screen you ended up on when you collected all of these details.

Posts In This Series (again)