Now we have established that Retailers are a special breed of organizations (see here) and their financials definitely deserve a special look. I think this difference in their operations has tremendous impact on their choice of applications. Some of the common notions of Oracle Applications such as Procure to Pay do not work for retailers.
Let me elaborate,
Procure to pay involves, at a high level involves
Creating Suppliers, Creating purchase requisitions/orders, receiving receipts, importing Invoices, Payment Processing/Check Printing, Post to GL.
However most retailers have a slight twist to each of these processes. I attempt to describe the differences below.
Creating Suppliers – Oracle eBusiness suite is often chosen as the master system for storing supplier data. However unlike other organizations, Retailers have a complicated network of suppliers, some of the supplier types are Raw Material Suppliers, Manufacturers, Brokers, Expeditors, Carriers, Factors, and Factories etc. These complex relationships help the retailer in getting the right product mix sourced, either manufactured or bought. This results in setting up a large volume of suppliers and various supplier sites usages for Ordering From, Returning To and Paying To.
Creating Purchase Requisitions/Orders – This is where Retailers often chose Retek (Oracle Retail) or other applications to create the tremendously large volume of purchase orders needed to source the variety of merchandise sold through their stores. Unlike an ERP application, retail specific applications tend to be better in performance and functionality. Creating POs in Oracle eBusiness suite needs all the items to be maintained in Oracle and this often can be cumbersome and performance intensive.
Receiving Receipts – Given the fact that Items are kept outside Oracle eBusiness suite, Receipts too are sent to a Retail application (such as Oracle Retail) which acts as the stock ledger. An interface to GL usually exists to post the receipt booking and any liability accrual postings.
Importing Invoices – Supplier Invoices for retailers are very high volume and are often matched to the PO and Receipt, this is usually done in a custom application as few packaged matching solutions given the accuracy that most Retailers need. Oracle Invoice matching (RIM) package does promise a better package but most Retailers already possess homegrown matching solutions that give a very high percentage of matching through custom rules. This high percentage of matching is often difficult to achieve with a packaged solution. However once the Invoices are matched, they can be imported in to the Oracle Payables module. Oracle Payables does offer a scalable and functionality rich solution for importing matched invoices and paying them.
Payment Processing/Check Printing- As I have indicated above, Oracle AP is often the system of choice for payment processing, be it EFT, Check or EDI. However separate check runs are done usually for Merchandise invoices and Expense invoices.
Post to GL – Posting the liability transactions is usually done using the Oracle AP to GL standard posting interface.
So as you can see there is a gap between the Supplier being created and Invoices being imported as the Items, Pos and Receipts are created in Retail applications. This is not an anomaly that needs correction, but a phenomenon that needs to be understood. Creating the individual retail stores, maintaining store level inventory and creating the huge amount of inventory transactions is not suited for Oracle eBusiness suite. And can be a performance nightmare.
Well, this is a point of view that I have started to subscribe to, what do you think about it? Sound off by posting your comments below!
