In my previous blog posts (Part 1 and Part 2), I reviewed the steps to configure the system, so it will read the bank transaction codes. Now I will review the import and upload process, which is the final step in manually loading your bank statements. The process is very simple because it is similar to the process for loading any FBDI or other zip files to the system. Before we get into these steps, first let me give you a few tips on how to be efficient with this whole process.

1. Download your files from the bank website in bulk. You should be able to download several bank accounts at once with a specified date range. By doing this, you can download all of your accounts for a full month, or possibly several months, depending on the limitations brought on by your bank. One of my clients had over 30 bank accounts and they were able to download a month’s worth of statements for all of them at once.
2. If each bank account’s statements download in separate files, just copy and paste the data into one file. This allows you to make one import/upload.
3. You MUST save the files in .txt format, then again as a .zip file. Fusion will not be able to read anything in the actual BAI format, but it can read .txt format.
4. When saving the files and the zip file, do not leave any spaces between the characters of the file name. For example, “BBVA JAN 2017” will not work, but “BBVA-JAN-2017” will. Don’t worry, though, if you upload with spaces, the process will end in error and the log file will tell you this is the issue.

Now that we’ve hit some key success tips, I’ll walk you through the import/upload process.

First, go to the “File Import and Export” screen and load using the ‘fin/cashManagement/import’ account option.

Then, go to “Scheduled Processes.” You will use the ‘Load Interface File for Import’ process, then use the ‘Process BAI2 Format Bank Statements’ as the Import Process and choose your zip file as the Data File.

If you do happen to receive errors or a warning, go to the Bank Statements and Reconciliation work area to see if the ‘Import error’ link gives you a reason for the rejection. If you see it’s because there is a missing transaction code, go add the transaction code, then click the Retry icon to resubmit the import process for that statement. Please see my previous blogs Part 1 and Part 2 for steps on adding transaction codes.

If no errors exist, you can start reconciling your statements right away! Notice that as you start reconciling, you can track how many lines are still unreconciled for each date (statement).

In the upcoming blogs, I’ll cover the reconciliation process along with autoreconciliation rules. You’ll be clearing out your statements in no time!

Now that you know where you need to add transaction codes in your Fusion instance, you must now make sure you classify them appropriately. In case you don’t already know, Oracle reads bank statements at both the header and line level, so you must add the codes to the proper mapping groups in the Manage Code Map Groups task.

Unfortunately, Oracle only provides a seeded balance code group with seeded values, as seen below:

Since you are defining these codes manually, you must also create a transaction code group. Best practice from Oracle suggests using the naming convention of CE_TRX_CODE, like so:

Go ahead and check the box for “Return Input if No Match” so that if there are errors reading these codes the statement lines can still be loaded with reasons provided for the errors. For example, if CE_TRX_CODE mapping does not include code 275, the system will load the statement and tell you that code 275 is missing from the mapping.

Now you will start adding your codes.

Review the BAI2 Bank Statement Overview file from your bank to determine the balance (header) codes versus your transaction (line) codes. You will have to add all of your balance codes to the CE_BALANCE_CODE mapping group and all of your transaction codes to the CE_TRX_CODES mapping group. The file I had from one bank labeled the header codes as “Summary” or “Status” codes, while all line level codes were labeled as “Detail”. Hopefully your bank provides enough descriptions for their codes so you can easily differentiate the two types.

Even though you have to add each code to the three FSM tasks – Manage Code Map Groups, Manage Bank Statement Transaction Codes, and Manage Cash Management Lookups – you should know that you only need to categorize them accordingly in the Manage Code Map Groups screen.

Next week, I will review the process for loading the bank statements. After that, I’ll run through some tips and tricks for managing your bank statement loads.

Throughout my career as a consultant, I have run into several clients that want to manually load their bank statements into Oracle. Since the implementation of electronic uploads can be time-consuming as well as out of the budget for some, there is a way around this. Loading bank statements manually can be done in the Cloud, and I am going to tell you how to do so over the course of my next several blog posts.

First, you have to determine the format of your statements. My experience has consistently dealt with BAI2 files, so that is where my expertise lies. If you are loading EDIFACT FINSTA statements, you may also be able to take some of these notes and apply this process to loading those as well, as they both have seeded configurations in the Cloud. Using the seeded BAI2 Bank Statements code map group works successfully and helps prevent additional configurations on the bank formats in the Manage Formats task.

Next, you need to get the BAI2 Format Overview from your bank. This provides the list of all the transaction codes that your bank uses. BBVA Compass generously provides the classifications of their transaction codes so you can determine the balance codes versus the transactional codes. This is important for the next few steps.

Now you will have to manually add all of these transaction codes to your Fusion instance. The important note to take away here is that Oracle doesn’t tell you these codes have to be added in three places to get the system to read them, but this is something I was able to figure out through my many painful hours of testing statement loads and consistent errors. I read several documents that stated the codes needed to be added in either the Code Map Groups task or the Manage Bank Statement Transaction Codes task, but I figured out they need to be added in both places as well as one more place.

In order for the system to read statements that are manually loaded, you must also add each code to the Manage Cash Management Lookups task in FSM. In this screen, you can search for the Lookup Code called CE_INTERNAL_BALANCE_CODES. In the Financials Generic Lookup Type section, you will need to add each transaction code. This enables the system to read each code that is imported. I used the “Common Set” reference data set so that all BBVA transaction codes will import successfully for any business unit using this bank.

In next week’s post, I will go into more details on determining balance codes versus transaction codes and where to plug in each type. Then, we will review the process for loading the bank statements.

Closing the General Ledger is the final step in the period close process. Now that we have reviewed the close process for the Financials subledgers (see previous blogs), you will now see how it all comes together in the ledger. Steps that are not included in this review are those involving the Procurement and Project modules, which will come at a later time. The steps for closing the ledger are as follows:

1. Verify that the status of the next period is set to Future Entry. This has probably been done automatically when the current period was opened, but it’s best to double-check this.
2. Run the Create Accounting process or subledger accounting in the Journals work area. This should push all transactions, payments, etc. to the ledger.
3. Reverse journals as needed by running the AutoReverse process from the Journals work area. Don’t forget to post these reversals.
4. Generate any allocations. You can run the Generate General Ledger Allocations process as well as the Generate Intercompany Allocations process, if applicable to your business processes.
5. Review any unposted journals by running the Journals Details Report from the Scheduled Processes screen. The Posting Status parameter can be set to Unposted Journals so that the user can analyze and resolve any outstanding journal issues.
6. Post all remaining journal batches by running the Create Accounting process one more time.
7. Now you can run the necessary reconciliation reports, Trial Balance Report, and Account Analysis Report to further verify all balances tie out.
8. Don’t forget about the intercompany reconciliation from the Intercompany module (if applicable). Run the Prepare Intercompany Reconciliation Reporting Information process to push all transactions to the ledger.
9. Next, enter any final adjustment or accrual journals as needed, and post them.
10. If currency conversions are implemented, you will then want to ensure all rates have been updated, balances have been revalued and translated, and have been accounted for.
11. Update the ledger periods by closing the current period and setting the new period to Open.
12. The last and final step is to reverse any accrual entries that were processed in the previous period.

Now that the ledger has been closed successfully, you are free to run your financial reports and start transacting in the new period. If you would like to see the order for closing previous subledgers, check out my blog called “Closing the Books? Follow This Order!” so you have a full understanding of the Fusion Financials closing process from beginning to end.

When closing Cash Management, the steps can slightly vary depending on whether or not your business has automatic or manual bank statements and reconciliations. The overall process is as follows for either process being used:

1. Load bank statements as your business process requires, whether this be manual or automatically from your bank.
2. Reconcile the statements. Depending on your business needs, you can reconcile against Payables, Receivables or the Payroll modules.  Reconciliation can be done either through submitting the Autoreconciliation process or through the Manual Reconciliation process. Again, this depends on how automated the instance has been delivered to you based on business requirements.
3. After either reconciliation process has been submitted, you can review the results and resolve any exceptions that are located in the Reconciliation region in the Bank Statements and Reconciliation work area.
4. If needed, external transactions can be created to balance the missing statement lines or any other exceptions.
5. Review the Reconciliation region again and resolve any additional unreconciled statement lines as necessary. Hopefully, the external transactions and reconciling of statement lines with subledgers has helped to resolve most of the issues already.
6. Run the Create Accounting process for any external transactions that were created.
7. Submit and review the Cash to General Ledger Reconciliation report to determine if anymore unreconciled transactions exist, then resolve as needed. Run this report from the Bank Statements and Reconciliation work area to capture all subprocesses. You can also submit several other reports that can help locate and resolve additional cash reconciling issues that may occur.
8. Lastly, you must correct any invalid entries that were created during this closing process. Reverse or edit any journal entries that have been transferred and/or posted to the ledger accidentally (if needed).

If you would like more details on the overall close process for Fusion Financials Cloud, please reference my blog “Closing the Books? Follow This Order!”

Closing the Fixed Assets module should be a quick and painless process each month. As most Oracle ERP users know, the module only allows for one period to be opened at a time, and once you close the period you can never re-open it again. I guess this can be both a good and bad thing – depending on how efficient your team is with keeping asset tracking up-to-date each month. There are a few simple steps you want to run through to ensure the module is closed properly and they are as follows:

1. Ensure that the Create Mass Additions process has been submitted through the Payables work area. This ensures that any invoiced assets have been pushed through to the Fixed Assets module and can be processed accordingly.
2. Once all assets are in the module, process them as needed – Capitalize, classify, update financial/descriptive details, etc.
3. Run the Create Accounting process. This will account for all the newly added assets and gives you the opportunity to see what is outstanding so you and your team can resolve any issues.
4. Run Depreciation. The ease of running depreciation is as simple as the click of a button. The Depreciation infotile provides a summary of all Period, Book, Ledger, Depreciation, and Asset information so you can do a quick review of what’s happened this month.
5. You can optionally choose to run depreciation as a stand alone process or you can run it in Close mode, which kicks off the depreciation process as well as closes the books. Of course, if you prefer to run depreciation separately from closing the period, you can do that as well. This final step is simply here to tell you to close the period.

When closing the Fixed Assets period, ALWAYS remember: You can NEVER go back once you have moved on. If you reference my previous blog called “Closing the Books? Follow This Order!” you will see the order of closing each module, so you will be able to reference where Fixed Assets fit into this process.

Thanks for taking the time to learn this simple process!

Closing the Receivables period is as simple as closing the Payables period. Some may even say it’s simpler. The following steps are best practice for performing this monthly process:

1. Open the new Receivables period.
2. Run the Create Accounting process. This ensures that everything that is outstanding is accounted for and ready to close out. Be sure to run this process from the Receivables work area to ensure that all Receivables subprocesses are kicked off as well including the Revenue Recognition process.
3. Review the Outstanding Subledger Transactions section on the Period Close dashboard. This will tell you anything that is still unaccounted for, what’s accounted for but not transferred to the ledger, and anything that has errors or is in draft mode. The beauty of this tool is that you can drill into the transactions that are listed here so you can reconcile/investigate as needed.
4. Run the Create Accounting process again, but make sure to run it from the Receivables work area.
5. Run the Receivables to Ledger Reconciliation report. This is very helpful in drilling into issues that you may not have been able to resolve from the Period Close work area. It allows you to drill into the differences balance and determine where the issues lie.
6. Once all the outstanding issues have been resolved, you can now close the period. Luckily, there is no sweep process to run for Receivables like there is for Payables.

Oracle provides several other reports that can be ran to determine variances as well, such as the Trial Balance Report, Adjustment Register, Transaction Register, etc. If you want to stay on top of any Receivables issues throughout the month, you can always run these reports to ensure business processes are running smoothly.

Running through the close process for Fixed Assets will come next, so check back soon for the tips on closing that subledger…

When closing the Payables period, there are some helpful reports to run that help in the reconciliation process. Even though there are plenty of other reports that can be used during period close, the Payables to Ledger Reconciliation report is the most helpful reconciliation tool available because it allows the user to drill into the differences between transactional and accounted activity. Once the user drills into the difference, they are able to see the exact transactions that are outstanding and can resolve any issues as needed, like so:

But first, it’s important to understand the steps involved to close the module properly.

1. Ensure all invoices and payments have been fully processed. This eliminates maintenance during reconciling.
2. Run the Create Accounting process to ensure that any outstanding items on the Reconciliation report are not there because of items not being accounted for.
3. If any invoices are sitting in the interface table or need imported, push all imported invoices through and complete as necessary. Running the Import Invoices process will bring in invoices that have been sitting in the interface table or are needed for an even period balance.
4. Ensure all invoice approvals have been completed. If any are pending approval, they will still need to go through the remaining steps to process and account for them before closing the period.
5. Next, you will want to review some other helpful reports that are available to reconcile, such as Payables Invoice Register, Payments Register, or Matured Bills Payable Status report.
6. If conversion rates are being used for multi-currencies, be sure and run the Apply Missing Conversion Rates process. This ensures that all foreign currencies have conversion rates applied.
7. Run the Create Accounting process again. If you have had to complete any of the previous steps, it is best practice to run this process again to capture any new activity and post to the ledger.
8. Optionally, you can sweep any questionable transactions to the next period. This is only for the issues that cannot be resolved before closing the period and needs to be reviewed again at a later date.
9. Close the period. Then, run the Payables Period Close Exceptions report. This checks for anything that failed in the accounting process.
10. Open the new period.
11. Next, review the Payables to Ledger Reconciliation report. This will show anything that could have slipped through the cracks while running through the previous steps, and as mentioned before, will allow you to drill down and see what the exact issues are.
12. Review the Trial Balance. There are a few other reports that can be ran for reconciliation and they are all listed in the Period Close folder in the Reports and Analytics work area.
13. Run the Create Mass Additions process to push all invoices including capital assets to the Fixed Assets module.
14. Review the Account Analysis report to ensure only necessary transactions were posted to the GL.
15. And finally, run the desired tax withholding or 1099 reports.

Hopefully this has been helpful, but even with the abundance of reconciliation reports that are offered by Oracle, the close process can be tedious. Even so, I think we all can appreciate these reports and processes during this process as a way to make life a little bit easier.

In the upcoming weeks, I will be reviewing the close process for several other modules.

The Period Close process can be a tedious and time-consuming task that can be the biggest headache for many. I have compiled a list of each subledger/module, along with the order of which to close them, as well as suggested reports to use to make the closing process a breeze. After all, it’s hard to know what module needs to be closed first to make the closing process successful, but with the list of period close dependencies that I will provide, the process can be easier and quicker than one may think. Knowing which reports are helpful along with the correct order in which to view them can make a major improvement on a company’s current business processes. When a client transitions into Fusion Cloud from a different ERP system, they will find that the processes, reports, and pages are very intuitive and provide the user with drill-down capabilities that will make the process easier than ever. The subledger to reconciliation reports that are available make it easier for the analysts to drill into each out-of-balance transaction or amount so they can fix the issue right then and there.

Here is the order in which to close the books:

1. Close Payables before closing Procurement. This is done to take into account the purchasing accruals at period end to accrue expenses on un-invoiced receipts.
2. Close Payables before closing Inventory. This ensures that the un-invoiced accrual entry is accurate.
3. Close Payables before closing Fixed Assets. This is done to ensure invoices are completed and capital invoice line distributions are transferred from Payables to Fixed Assets.
4. Close Payables before closing Projects. This is to ensure invoices and expense reports are completed and transferred to Projects.
5. Close Procurement before closing Inventory. This is to allow miscellaneous transaction corrections in Inventory.
6. Close Inventory before closing Projects, so that Project-related inventory transactions are completed and imported into Projects.
7. Transfer all relevant Project costs to Fixed Assets, then transfer revenue to Receivables before closing Fixed Assets and Receivables.
8. Close all subledger applications before closing General Ledger.

Since the close process can be difficult to follow in the correct order, hopefully this bit of information has been helpful. In the upcoming weeks, I will discuss a few key points to consider when closing each subledger as well as recommended reports to run.

As we all know P2T (production to test) copies happen frequently within a project timeline and after Go Live. Some files tend to ‘disappear’ or lose important data after a P2T. There are some simple fixes to this issue, with the first being that you need to start saving these files locally. If they are saved to the right folder, you are going to keep them. If you don’t you’re going to lose all your hard work…just like that. The Financial Reporting Studio is the best tool to use for creating high-quality, boardroom-ready reports. I’m sure you already knew that. But, have you ever gone in to review a previously finished/saved report after a P2T? Or do you always lose access? Well, there are a few steps you can try to fix this without having to start all over.

First, you want to check the database connection. If the connection has been changed, go ahead and change it to the correct connection. If your reports still won’t open, usually giving an error regarding an “unknown member in the Essbase” then there’s something else you can do to fix it.

1. Open your desktop client of Financial Reporting Studio.
2. Login, then locate the report you need to fix.
3. Note that your accounts listed in each cell now show as some crazy mess of numbers. You know those aren’t your account numbers, so what’s going on?
4. Even though it may seem tedious, all you need to do is re-add the accounts (members) to the desired cells.
5. Save the report, then open in the Web view.

   Bad Accounts:

Good/Valid Accounts:

See? Now everything looks good and you don’t have some crazy mess of numbers showing as account numbers…and now you can easily open your reports to see them exactly the way you want them. Believe it or not, it took my team a good bit of time to figure this out, but that’s because it was something that seemed to be too easy of a fix. Hopefully you now understand the importance of saving your report to the correct folder so you don’t have to do this, but this will come in handy just in case. Hope this helps!

As I have discussed before, FBDI is the best tool for loading mass amounts of data. When you’ve got a client that has thousands of suppliers – which let’s be honest, they all do – then FBDI is your best friend. Instead of manually entering the data into the system one click at a time, save yourself the headache and copy and paste the clean file’s data into the FBDI for Suppliers. The key thing to remember when loading your Supplier information is that there are multiple FBDI’s for completing the entire process. The reason for this is because Oracle Fusion Cloud does not require, nor does it enjoy, having the same address entered in twice. This means that the supplier addresses has it’s own separate FBDI. Then there is another file for the supplier names, supplier sites, and site assignments…but that’s not the order of how they should be loaded. Here’s the proper order, and it really does make sense to do it this way if you know the forms well enough:

1. Suppliers – This includes the name, supplier number (if the client wishes to keep their current numbers), description, tax information, and payment method, as well as any additional attributes you may need.
2. Supplier Addresses – Some suppliers are located at different addresses across the country or the world. Having a separate import of data that is specific for all address details is what Oracle has considered and why they have provided us with the simplicity of adding them separately.
3. Supplier Sites – Supplier sites can be a confusing concept for many clients to grasp at first, but once they learn how great the sites are and what the purpose of them is they really learn to love it. Sites are the best way to break down a company by department, location, etc. This eliminates the need to enter in supplier details multiple times…instead, just add a new site!
4. Supplier Site Assignments – This is one of the most important steps when creating any supplier. It is imperative that each supplier site have it’s BU assignments set. If this is not done, it is impossible for the instance to know which supplier sites have access to the desired business unit. If a site is not assigned, it cannot create invoices, payments, etc. for the given supplier.

Note: Sites can include multiple addresses, but each address is only entered in once.

You can also update supplier information in the FBDI file, meaning it’s not just great for creating suppliers, but also great for updating already existing suppliers if you have a saved copy of the file on your computer. Managing suppliers has never been easier! The trick is to set up a clean template for use with each client and have it ready to go. Once everything is set, filling in the blanks is the easy part.

The Manage Administrator Profile Values task in Setup and Maintenance is an excellent tool for troubleshooting issues throughout any of the Fusion applications. There have been several scenarios where access levels have been removed or a simple configuration may have been missing. For a majority of these scenarios, the answer was found in this task screen.

Allow me to list just a few examples of issues that were resolved by fixing setups in Manage Administrator Profile Values:

1. When adding the ability for users to edit account strings in expense reports.
2. When adding project details to a PO in Procurement.
3. When a data access set and business unit have the same naming convention.
4. When AR transactions do not have LOV of business units.
5. When adding users to set the default Business Unit.
6. Changing the Alias for segment values in Financial Reporting Studio.

Production to Test copies are meant for overriding incorrect data and configurations, but sometimes they wipe out more than intended. All of the examples I listed above were issues that occurred after a P2T and were issues that were very time-consuming to troubleshoot, but with the help of Manage Administrator Profile Values, the issues were resolved. Authorization Policy Manager (APM) is another good place to check for roles and access level issues, but sometimes they conflict with Profile Values set in the Manage Administrator Profile Values task. It’s best to check both areas to ensure all setups are correct based on the client’s requirements.

Profile Levels can be enabled for:

1. Users
   1. Can specify only specific users to have access.
2. Specific product
   1. Can specify the profile value for a product such as Expenses, Receivables, Purchasing, etc.
3. Site level
   1. Can be set for site level so all users have the profile value.

The Profile Value should be set for the desired profile level then the specific profile value, which can be the data access set, access permissions of Yes or No, or can even be free form.

The main idea here is to inform you of the many setup options that are available in your Cloud instance that you may not have known about or thought to check. Most of the time the issue is not a bug, so let’s not bother Oracle Support with it unless we have exhausted all research tactics. Next time you have a setup issue, check the Manage Administrator Profile Values task first. You’ll be surprised at what you can find there.