АРГУС Resource Management System
В условиях большого количества различных товарно-материальных ценностей, крайне затруднительно вести их учет без использования специализированного программного обеспечения.
Система АРГУС Resource Management System позволяет оптимизировать работу служб складов, отделов эксплуатации и финансовых служб компании. АРГУС RMS призвана обеспечить сквозной автоматизированный учёт движения материальных ресурсов: сетевого оборудования, ИТ-оборудования, программного обеспечения, комплектующих, ЗИП, расходных материалов — т.е. всех материальных активов.
Продукт эффективно закрывает переход от систем поддержки эксплуатационного управления к системам управления ресурсами предприятия. Функции управления жизненным циклом опираются на мировые стандарты и лучшие практики в области управления ресурсов (Resource Lifecycle Management), благодаря чему система RMS легко интегрируется в IT комплекс современного предприятия и его процессную структуру.
Инструкция для клиента по работе в РМС
RMS (Requirements Management System — Система Управления Требованиями) — это веб-система управления проектами, с помощью которой организуется разработка программного обеспечения и учетных систем силами распределенных проектных команд. При работе над продуктом мы используем собственную проектную технологию, разделяющую основные ценности гибких (Agile) методологий:
- Люди важнее процессов и инструментов
- Работающий продукт важнее исчерпывающей документации
- Сотрудничество с заказчиком важнее согласования условий контракта
- Готовность к изменениям важнее следования первоначальному плану
Для реализации этих принципов мы привлекаем к работе заинтересованных представителей заказчика и, при необходимости, представители организаций-партнеров, принимающих участие в формулировке требований и управлении процессом разработки программного продукта. Вместе с клиентом специалисты нашей компании проводят цикл работ по анализу и достижению понимания потребности клиента, проработке модели решения потребности, настройке, разработке, тестированию и передаче решения заказчику.
Top 7 Microsoft RMS replacements in 2023
Microsoft discontinued its Dynamics Retail Management System (RMS) in 2015 and officially ended its extended support in July 2021. After this time, retailers had to switch to another POS system for continuous experience and support, as well as to meet their demand for an omnichannel approach. This article will give you details of Microsoft RMS POS, what you have to do after it was shut down, and the top Microsoft RMS replacements you can consider for your retail company.
-
– Best omnichannel POS for Magento retailers – Best cost-effective all-in-one – Best for multi-channel selling – Best for fast setup and customization – Best inventory customization – Best reporting features for midsize and larger businesses – Best for midsize businesses
What does Microsoft RMS end of life mean?
What is it?
In 2015, Microsoft announced that their retail point of sale solution—Microsoft Dynamics Retail Management System (RMS)—was reaching its end of life. At the beginning of 2016, new customers could no longer purchase the RMS software, and mainstream support for RMS officially stopped on 10th July 2016. After that, Microsoft continued its extended support for existing customers until 13 July 2021 with an annual maintenance fee.
What happens after the event?
For over 45,000 companies using RMS at that time, once the extended support ended, they had to switch to another alternative solution to avoid disrupting their operation. Retailers moved away from the outdated RMS and are turning to more modern services with an omnichannel approach to commerce. This has become an evolution for POS systems to provide real-time sales and inventory visibility, sync data across sales channels, and integrate more functionalities to control all processes, from acquiring inventory to selling and customer services.
4 Oracle Retail Merchandising System
This chapter gives an overview of the information maintained by RMS and RMS integration with other applications.
Information Maintained by RMS
RMS is the System of Record (SOR) for the following:
Seed Data
RMS contains data that must be populated at the time of installation. Either the data is required by the application, or the data is static and can be loaded for any client. The code tables CODE_HEAD and CODE_DETAIL are examples of tables with system-required values that must be loaded at the time of installation. Additional codes can be added as needed to these tables after installation, by either using the online form or additional client scripts. Customization of the seed data is based on the client’s requirements.
Additionally, some configuration tables must be populated for the application to open and function correctly, even though the configuration values can be modified later. These configurations are maintained in System Options set of tables, and are required for initial setup that can be updated prior to the implementation, to reflect final configuration.
Foundation Data
Foundation data is the base for all future information on which RMS builds. This information needs to be present before you begin using the system. The majority of foundation data can be set up online; more commonly, a client performs a data conversion process to import this information from legacy systems.
Foundation data consists of three types of information:
Supplier and partner management
Organization Hierarchy
The organizational hierarchy allows you to create maximum of six levels of hierarchy relationships to support the operational structure of your company.
In a Retail store, the customer walks through the store and buys, retails procure goods from suppliers and the retailer acts as a customer. In a Franchise store, the retailer supplies goods to the franchise customers, the retailer acts as a supplier and tracks the sales.
You can create a preferred organizational structure to support consolidated reporting at various levels of the company. You can also assign responsibility for any level of the hierarchy to one or more people to satisfy internal reporting requirements.
The organizational hierarchy also supports two types of stores to satisfy the franchise requirements:
A company store act as retail store in RMS.
The Franchise stores are used to support franchise business models. Other applications, such as RWMS, view franchise stores as they would view any other store in RMS; however, RMS performs special processing based on the store types.
Merchandise Hierarchy
The merchandise hierarchy allows you to create maximum of six levels of hierarchy relationships to support the product management structure of your company. You can assign a buyer and merchandiser at the division, group, and department levels of the merchandise hierarchy. You can also link a lower level to the next higher level. For example, you must indicate to which group a department belongs, or to which division a group belongs.
Supplier and Partner Management
A supplier supplies the merchandise and a partner is involved in other financial taxation that results in an invoice. Supplier and partner management provides functionality to create and store valid merchandise suppliers and partners. You can maintain a variety of information about suppliers such as financial arrangements, inventory management parameters, types of EDI transactions, and invoice matching attributes. Suppliers are typically created in a financial system and interfaced into RMS. Supplier enrichment can be maintained in RMS.
The supplier structure can be extended to supplier-parent and supplier-site relationships, to accommodate financial systems that support this configuration. A supplier site is a location from which the supplier ships merchandise.
Item Maintenance
RMS is responsible for the creation and maintenance of all items. RMS uses a flexible data hierarchy for an item, with levels that allow you to model items in a desired way. The hierarchy consists up to three levels, highest (level 1) to lowest (level 3). Within the defined levels for an item family, one level is denoted as the transaction level. This is the level at which all inventory and sales transaction takes place. This model gives retailers a flexibility to create families of items that share common characteristics.
RMS creates several types of items, such as regular items, deposit items, packs, concession items, consignment items, and transformable items.
Through item maintenance, RMS also maintains the relationships of items with other entities such as suppliers, locations, and attributes.
Purchasing
The Purchase Order module allows you to create and maintain purchase orders in a variety of ways. It provides commitments to vendors for products in specific amounts for specified locations. Purchase orders are created manually or automatically through replenishment or from an external system. They can be created against entered contracts and deals, or directly through direct store delivery or Vendor Managed Inventory (VMI). RMS also provides the ability to maintain the items, locations, and quantities ordered for Purchase Orders.
Contracts
The contract dialog gives you the ability to create, maintain, submit, and approve contracts. A contract is a legally binding agreement with a supplier to supply items at a negotiated cost.
In RMS, the contracting functions fit closely with the replenishment and ordering functions. The main functions of the Contracts window are to book manufacturing time, track supplier availability and commitments, and match them with business requirements. The main business benefit of contracting is to achieve supplier involvement during the planning phase of a retailer’s business.
Deals
Deals management allows you to create and maintain deals with partners or suppliers. Deal partners can be suppliers, distributors, and manufacturers. Within a deal, clients create deal components, specify the items for each deal component, and define thresholds.
Components are deals or parts of deals that a retailer receives from a supplier. There can be multiple components in a single deal. You must define thresholds to define the quantity or amount that must be purchased or sold to receive the deal. RMS components include off-invoice deals, rebates, vendor-funded promotions, vendor-funded markdowns, and fixed deals.
You also define the items and locations for which the deal can be applied. You can choose to include or exclude locations as necessary.
You also define the Proof Of Performance (POP) terms for a deal. POP terms are defined by the deal vendor that offers the deal. For deals, POP terms are defined at the deal, deal/component, or deal/component/item-location combination. For fixed deals, POP terms are defined at the deal level.
The deal pass-through functionality allows a percentage of a deals discount to be passed from a warehouse to a franchise store. This functionality applies to franchise stores.
For clients that choose to use supplier sites with RMS, deals are managed at the supplier parent level.
Cost Management
For cost changes, the Cost Management dialog gives you the ability to:
Accept cost changes received through EDI (flat files)
Create a cost change
Edit a cost change
View a cost change
A cost change is an adjustment to the supplier cost of an item, either up or down. Before you create a cost change, you must create a list of user-defined cost change reasons and then apply a reason to each cost change. This is useful in reporting.
The initial cost of an item is established at item setup. The cost of the item is adjusted in the item record until the status of the item is Approved. After the item is approved, any cost changes needs to be handled through the cost change dialog.
When a cost change is submitted through EDI, the EDI cost change is reviewed and released to create a cost change document. The cost change document is then viewed and submitted for approval.
When a cost change document is created online, you enter the cost change, an event description, an effective date, and a reason code, and then submit the cost change for approval.
After a cost change is approved, the item/supplier cost record is updated. Any outstanding purchase order line items with no received units are recalculated, if recalculation is indicated on the cost change.
Additionally, you use the Cost Management dialog to create cost zone groups for zone-type expenses for item estimated landed cost. Zone-type expenses are incurred when imported goods are moved from the discharge port to the purchase order receiving location. Because the expenses can vary depending on the distance between the discharge port and the receiving location, cost zones can be configured to appropriately reflect the expenses. The locations (stores and physical warehouses) must be grouped to reflect the expense variances for moving the goods. Normally a zone strategy is used for these cost zone groups, but it is possible that every location within the company has different expenses to move the goods from the discharge port. If that is the case, a store strategy would be used. If every location within the company has the same transportation costs from the discharge port, a corporate strategy is adequate (but not when multiple currencies are being used). After these cost zone groups are defined, they are added to new items as they are created, in anticipation of the expense profiles that are needed for the items.
Multiple Set of Books
Support for multiple sets of books provides better integration with financials systems that supports Multiple Sets of Books within a single installation. Multiple Sets of Books option is enabled by default in RMS and the client will need to set up additional location-specific foundation data, including:
Set of books IDs
Inventory Control
Inventory functionality in RMS is the core of the application. Inventory is tracked perpetually and financially in RMS. The following describes perpetual inventory tracking. For information on financial inventory tracking, see Stock Ledger.
RMS achieves inventory control through functions that include transfers, Return to Vendor (RTV), Inventory Adjustments, Sales Upload, Purchase Order Receipts (shipments), Stock Counts, Allocations, Franchise Orders and Returns, and Customer Orders.
Transfers
Transfers in RMS provide an organized framework for monitoring the movement of stock. RMS creates and maintains transfers; however, you can also interface transfer information into RMS from other systems.
RMS supports a number of different types of transfers such as intercompany transfers, book transfers, Purchase Order-linked transfers, externally generated transfers, customer orders and franchise order. Transfer functions also support the movement of one or more items between two internal RMS locations, and multi-leg transfers in which the intermediate location is considered a finisher location. Finishers are locations where work is performed on merchandise, such as dying fabric and attaching labels.
Mass return transfers are used to reallocate merchandise to locations or to return merchandise to the supplier.
Returns to Vendor
Return to Vendor (RTV) transactions are used to send merchandise back to a vendor. The RTV transaction in RMS allows one or more items to be returned to a single vendor. For each transaction, the items, quantities, and costs are specified. Upon shipment out of a location, inventory is removed from the stock on hand.
RTVs are created manually in RMS or imported from an external system. RMS also provides the ability to maintain RTVs. Shipped RTVs create a debit memo or credit note request (based on supplier configuration) in the invoice matching staging table in RMS, for export to Oracle Retail Invoice Matching.
Inventory Adjustments
Inventory adjustments are used to increase or decrease inventory to account for events that occur outside the normal course of business (for example, receipts, sales, stock counts). Inventory adjustments are created in RMS or imported from an external system (store or warehouse application). RMS supports two types of inventory adjustments; stock on hand or unavailable inventory. Inventory adjustments can also be created by locations for multiple items, by item for multiple locations, or through a product transformation for a specific location.
Reason Code 1 — Used for wastage adjustments
Reason Code 2 — Used for adjustments against processed stock counts
Reason Code 13 — Used for inventory adjustment for unavailable receipts
Reason Code 190 — Used for inventory adjustments related to ‘destroy on receipt’ situations for Wholesale and Franchise
Reason Code 191- Used for Customer Returns without inventory
Additionally, reason codes must be synchronized between SIM and WMS, or any other system communicating inventory adjustments to RMS.
Purchase Order Receipts (Shipments)
Purchase order receipts (Shipments) record the increment to on-hand when goods are received from a supplier. Weighted average cost (WAC) is recalculated at time of receipt using the PO landed cost. Transaction audit records are created for financial audit, and the receiver is made available for invoice matching.
Stock Counts
Stock counts are the processes by which inventory is counted in the store and compared against the system inventory level for discrepancies. RMS supports two types of stock counts:
Unit Stock Counts: These adjust the on hand quantities for the item-locations affected and create an inventory adjustment transaction for the stock ledger.
Unit and value stock counts: These adjust the on hand quantities for the item-locations affected and adjust the stock ledger to the results of the stock count.
Replenishment
Automated replenishment constantly monitors inventory conditions. Based on inventory conditions, purchase orders or transfers are created to fulfill consumer demand.
Automated replenishment parameters are set up at the supplier, supplier/department, and supplier/location or supplier/department/location level. These parameters include:
Review cycle and order control
Due order processing
Investment buy attributes
Truck splitting constraints
Items can be set up for automated replenishment through the Item Maintenance dialog, either individually or through item lists.
Automated replenishment also supports different methods to determining whether purchase orders are created and quantities ordered. These replenishment methods are applied at the item/location.
Constant is a stock-oriented method in which the item is replenished when the inventory level falls below a specified level.
Min/Max is a stock-oriented method in which the item is replenished up to the maximum when the inventory level falls below a specified minimum stock level.
Floating Point is a stock-oriented method in which the item is replenished when the inventory level falls below a dynamic system-calculated maximum stock level.
Time Supply is a stock-oriented method in which replenishment is based on the number of days of supply for the item a retailer wants in inventory. The Time Supply method requires a forecasting system.
Time Supply Seasonal is the same as Time Supply, but it takes seasonality and terminal stock into account. The Time Supply Seasonal method requires a forecasting system.
Time Supply Issues is used only by warehouses, this is the same as Time Supply, but it uses warehouse issues forecast rather than store sales forecast. The Time Supply Issues method requires a forecasting system.
Dynamic is a method that controls inventory using dynamic calculations of order point and order quantities based on a number of factors, including forecast sales over order lead time, review lead time, inventory selling days, lost sales factor, and safety stock. The Dynamic method requires a forecasting system.
Dynamic Seasonal is the same as Dynamic, but it takes seasonality and terminal stock into account. The Dynamic Seasonal method requires a forecasting system.
Dynamic Issues is used by warehouses only, this is the same as Dynamic, but it uses warehouse issues forecast rather than store sales forecast. The Dynamic Issues method requires a forecasting system.
Store Orders is a method that allows replenishment to look at the store order need quantity when determining the recommended order quantity.
Franchise Management
The Franchise Management allows the retailer to manage their franchise business in the following scenarios:
Retailer owns and manages the inventory for a franchise location .
In this case, the franchise customer (location) needs to be set up as stockholding stores in RMS, with a store type as Franchise. A stockholding franchise store functions similar to a company store with locations of inventory transactions such as Replenishment, Allocation, Stock Counts and Inventory Adjustments being allowed for such stores in RMS. The main differences in these stores are, the way in which the orders are captured and accounted financially.
Retailer does not own or manage inventory for a franchise location.
Here the retailer does not manage the inventory for a franchise location or wherein the wholesale operations constitute a small fraction of the retailers business and thus does not warrant a separate Order Management System.
In both these scenarios, non-stockholding stores must be setup in RMS to represent these franchise (or wholesale) customers.
Franchise Pricing
Franchise pricing determines the price that is charged on a franchise partners for an item. Pricing for these stores is maintained in the future cost table. The pricing for franchise locations are determined by setting up cost templates in RMS and associating these templates with an item or a franchise location. Franchise pricing includes any landed costs and applicable deals through deal pass-through to the final pricing.
The user has an option to override the future cost franchise price and instead define a fixed price to be charged for an item for manually or through the batch upload orders.
Franchise Ordering
Franchise store can source the merchandise from company locations (Warehouse or Store) or from a supplier. The franchise order can be initiated manually using the franchise order form or by an batch upload process using flat file received from an external application. The franchise order created using the flat file also creates a purchase order for supplier sourced and transfers for company location sourced orders.
In addition, franchise order gets initiated in response to any inventory transaction process where the receiving location is a franchise store and the sending location is a company location or supplier. Some of these inventory transactions are Replenishment Requests, Allocation, Store Orders, Items requests; AIP generated Purchase Orders or Transfers, and externally generated transfers.
Franchise Returns
Franchise stores returns the items back to the company location (warehouse or store). Item return from a franchise store directly to the supplier is not allowed. The franchise returns can either be a physical return to the company location or can be a book return. Book Return is possible when the item is destroyed at the site, in such scenario the inventory is not physically returned but can be financially accounted.
The franchise return can be initiated manually using the franchise return form or by batch upload process using flat file received from an external application. Franchise returns results in creating a transfer to track the inventory movement.
In addition, franchise returns gets created in response to any inventory transaction where the sending location is a franchise store and receiving location is a company location. Some of these processes are AIP or externally generated transfers.
Stock Ledger
The stock ledger in RMS records the financial results of the merchandising processes such as buying, selling, price changes, and transfers. All of these transactions are recorded in the RMS stock ledger and rolled up to the subclass/location level for days, weeks, and months, depending on calendar settings. The aggregate levels in the stock ledger are used to measure inventory amounts and merchandise profitability. The stock ledger is mainly used for reporting purposes; however, there is some online visibility as well.
The stock ledger supports multiple currencies. All transaction-level information is stored in the local currency of the store or warehouse where the transaction occurred. As transaction-level information is rolled up to the aggregated levels in the stock ledger, records are kept in local currency and converted to primary currency. This allows corporate reporting to be performed in the primary currency of the company, while still providing visibility by location to the profitability in the local currency.
The stock ledger supports both the retail and cost methods of accounting. The cost method can use standard cost or average cost, depending on how the system is configured. The stock ledger supports both the retail (4-5-4) and the normal (Gregorian) calendar. If the retail calendar is used, data is maintained by the 4-5-4 month and the week. If the normal calendar is used, data is maintained only by the Gregorian month. Data can also be maintained daily using the retail (4-5-4) or normal (Gregorian) calendar.
RMS supports multiple sets of books. Clients that use multiple sets of books assign
RMS locations to a particular set of books defined in an external financial system. Changes to the stock ledger affect the set of books with which a particular transaction is associated.
Investment Buy
Investment buy facilitates the process of purchasing inventory in excess of the replenishment recommendation in order to take advantage of a supplier deal or to leverage inventory against a cost increase. The inventory is stored at the warehouse or in outside storage to be used for future issues to the stores. The recommended quantity to investment buy, that is, to order, is calculated based on the following:
Amount of the deal or cost increase
Upcoming deals for the product
Cost of storage
Forecasted demand for the product, using warehouse issue values calculated by Oracle Retail Demand Forecasting
Target return on investment (ROI)
The rationale is to purchase as much product as profitable at the lower cost and to retain this profit rather than passing the discount on to customers and stores. The determination of how much product is profitable to purchase is based on the cost savings of the product versus the costs to purchase, store and handle the additional inventory.
Investment buy eligibility and order control are set at one of these four levels:
Supplier-location (warehouse locations only)
Warehouses must be enabled for both replenishment and investment buy on RMS WH (warehouse) table.
The investment buy opportunity calculation takes place nightly during the batch run, after the replenishment need determination, but before the replenishment order build. The investment buy module IBCALC.PC attempts to purchase additional inventory beyond the replenishment recommendation in order to achieve future cost savings. Two distinct events provide the incentive to purchase investment buy quantities:
A current supplier deal ends within the look-ahead period.
A future cost increase becomes active within the look-ahead period.
The calculation determines the future cost for a given item-supplier-country-location for physical warehouse locations only.
If the order control for a particular line item is buyer worksheet, it might be modified in the buyer worksheet dialog, and can be added to either new or existing purchase orders.
RMS Integration with Other Applications
RMS provides essential information to all of the Oracle Retail Merchandising Operations Management applications (ReSA, RTM, ReIM, Allocation), and interacts with all of them. RMS exists on the same database schema as all of the other applications, which provides flexibility in how information is shared between RMS and the other Oracle Retail Merchandising Operations applications.
Information is shared with other Oracle Retail Merchandising Operations Management applications through direct reads from Oracle Retail Merchandising Operations Management application tables, calls to Oracle Retail Merchandising Operations Management application packages, batch processes, and the Oracle Retail Integration Bus (RIB) if the client is using this option.
The following diagram illustrates the RMS location in the merchandising footprint.
Figure 4-1 RMS Location in the Merchandising Cloud Services Footprint
RMS and RTM
Oracle Retail Trade Management (RTM) and RMS share the same database instance. When RTM is enabled in an RMS instance, certain import-specific data maintenance is required for country, supplier, partners and items. These are directly updated into the RMS database and subsequently used in RTM.
RMS and ReSA
Oracle Retail Sales Audit (ReSA) and RMS share the same database. ReSA shares some of its master data with RMS. Foundation data such as stores a company/location close dates, location traits, bank setup and tender types are maintained in RMS and used in ReSA.
Sales Upload Process
Current reference data is retrieved from RMS into ReSA by the batch program SAGETREF. The data is extracted into multiple data files. The data in the files is used by the batch program SAIMPTLOG as reference data for doing validation checks on the POS/OMS transaction data during the data upload to ReSA. Having the reference in data file formats increases the performance of the SAIMPTLOG process. SAGETREF generates the following reference files: