Most of the time, when you order something, you get something; and when you get it, you have to let the system know it’s been received so that the invoice may be paid. You don’t want to pay invoices for something that never arrived, and if something has arrived but the invoice has not, you still need to record the fact that sooner, rather than later, you will need the cash on hand to pay for the item you purchased.
Yet far too often, once the physical items have arrived, users quickly forget about the data entry task of confirming the receipt. The fact that an invoice is on hold, seems more like an Accounts Payable problem, and many end users wouldn’t know where to find the AP team even if they wanted to. Out of sight, out of mind. But it’s a big problem at most, if not all, clients.
There are a few things that can help alleviate this issue. One of them is migrating quickly to the “Responsive” application for self service receiving. The “ELI5” for “Responsive” applications in general is that Oracle Fusion Cloud is in the process of migrating from the original, or legacy, “ADF” based pages, to new “Redwood” based pages. You may see Redwood called a “theme,” because it has a distinctive look and feel and theme is a word we use to define different look and feel, but Redwood is not just a theme for the page. A Redwood page is a page that has been built using Oracle’s new tool Visual Builder Studio, which allows you to develop with “low code” because it’s built by using Rest APIs to pull and push information in and out of the page.
A significant amount of bandwidth at Oracle is dedicated to rebuilding all existing pages on Redwood. It’s only a matter of time until 100% of the pages are available as Redwood, and in the meantime, the pages that are built on Redwood are being called “Responsive” pages. I’m pretty open about my opinion that this is not a good name for the pages, because it implies that the legacy pages are un-responsive, and I prefer to either call them Redwood pages, or if possible, simply implement only the Redwood page and never expose the client to the legacy page at all.
As of this post, there are 3 Redwood pages available for procurement: Self Service Requisitioning, My Receipts, and Supplier Registration. Some require an opt in, others require configuration steps to load some background tables, as well as scheduling processes and creating custom roles. That’s right, even though Redwood is the future of Oracle, using the pages requires custom security roles. Even on Oracle Demo Cloud pages we run into this issue. For example, Camille Fredricks user has access to the new Requisitioning page, but no users have access to the new My Receipts page. I don’t understand why, if Redwood is the future (and it is, no doubts about that), Oracle makes it harder to access. That opinion and $2.50 will get you a cup of tea.
My recommendation is to migrate immediately (well, as quickly as possible considering an implementation project is 1-3 years long) to the Redwood page for SSP. Within that page, there are new statuses that make it easier for end users to see that a requisition has been invoiced but not received, compared to the legacy page that requires them to drill into My Requisitions.
You can also migrate to the new Responsive page for My Receipts, which makes it easier to process receipts along with edits and corrections all in one place. The Redwood theme pages also load beautiful on mobile devices, so users can process receipts from their phones, tablets and more.
If you want an extra layer of alerts, the same processes that run for daily updates of the new SSP page, also populate a field in Requisition Lines, the Action_Required_Code. You can use this data to build a report with deep links and bursting to alert users when an action is required such as receiving, fixing prices, and more.
A third option that I almost always recommend is using the receipt notification process to send alerts to users. There are a few parameters that control this process. First, the emails are only sent when the process is run. And once an order is picked up by this process, it stays in the queue for up to 14 days. It will be returned to the list to be re-sent out by email after that time, or if the users select that they haven’t received the item. Next, you can control whether notifications are sent only when the order is past due and invoiced, or when it is simply past due regardless of whether it is invoiced or not. Finally, you can control whether it is sent to the buyer when an end user indicates that it is not received yet, or if the buyer doesn’t get a notification. I should mention this option is only for expense items which don’t require details to be stored upon receipt like lot number.
Usually, we set it up to run once per day, we send it only once past due and invoiced, and we escalate to the buyer.
The end users get an email with the line details showing what was ordered, the price, the quantity, the invoiced amount and details, and they are given three options:
- Receive in Full: Receives the ordered amount, even if the invoice was more or less
- Receive up to Invoiced Amount: Receives the invoiced amount, regardless of whether it is more or less than the order
- Did Not Receive: Doesn’t receive anything, either sends the order back to the list of orders to be sent out in notifications upon next scheduled job run, or sends to the buyer to review.
This way, users who don’t log in to Oracle very often, can simply hit the button in the email and process the receipt. Making it easier for end users to process receipts, always leads to higher compliance and fewer issues.
There is one more neat trick for this alert, which isn’t obvious from the settings how to achieve. Sometimes, clients want to remove the “Receive in Full” option. It is possible by editing the BPM task ConfirmReceiptFYIAction. Go to the Access tab, look for the Task Action that mentions ReceiveInFull, and uncheck all individuals with access, and the button will disappear.
Invoice matching is a topic that can keep a table of procurement and payables users talking all night. We want to do everything we can to make it easier for users to process receipts, just like we want to make it easy to bring in invoices through features like IDR. Fortunately, Oracle Fusion Cloud provides us several ways to help achieve higher compliance on receipts. What’s your biggest challenge to solve in your ERP?