This query was designed to help mitigate issues with employees having multiple Expenses profiles that could potentially be under different GL Units. When Running the QFS_EX_TRANS_IN_PROCESS Query by GL Unit, it displays all Expenses transactions In Process (In Process ≠ Closed, Denied, Reconciled, Paid (ER’s only)) for your GL Unit. If you run it by ID (Empl ID), it will display transactions in process by Empl ID, even if those transactions were entered under a different GL Unit.

This is important information (especially when onboarding new employees). It is recommended to allow transactions in process at other institutions to complete processing (Status = Paid) before moving the default profile of an Expenses profile from that other institution to another.

The System will stop you from submitting and paying out an Expense transaction that has a Profile number mismatch (the record used to create the transaction does not match the current default profile #) if you are using chartfield values that do not match the current default profile #.

For example; As a Travel Admin, you created Expense report 123445 for Joe Smith under Profile # 1, entered one expense line, and saved it.. The next day, another college updated the default profile of Joe to profile #3. Two days later, you go back to Expense report 12345, with a goal of completing and submitting it that day. But the system will not allow you submit it, as it is giving you an error message, indicating the Default Profile number has been changed since ER 12345 has been created. At this point, you would want to run the query QFS_EX_TRANS_IN_PROCESS to see if there are any other transactions in process for Joe Smith to see what your options are. If there are no other transactions in process for Joe, then temporarily change the default profile back to #1, so that you can complete processing of ER 12345, then update the default profile to #3. It would also be best practice to reach out to the Travel admin of the Institution for Profile #3 if you have that information to let them know that you have temporarily changed the default profile back to #1.

The System will NOT stop you from submitting and paying out an Expense transaction, when there is a Profile # mismatch, if you are entering chartfield values that match the current default profile. You will need to take extra care, and point out in training that your users should never have to switch the Oper Unit and GL unit in the accounting values of their EX transactions. If they do, that is their clue that the transaction was created under the wrong profile # and simply updating those chartfield values does not change ownership of the transaction. The transaction will need to be deleted and created under the correct Default Profile number.

If updating the default profile to correct the mismatch is not possible due to the Profile number being at a different GL Unit, then that transaction will need to be deleted and re-entered under the correct GL Unit.

If you notice that there are transactions in process for another GL Unit and the Default profile is also set to that other GL Unit, we recommend waiting for those transactions to be fully processed before you update the default profile to your GL Unit.