Nearly every company agreed, back in the mid-eighties, that the aged mainframe based system environment they had been operating under for the last decade had to go. First implemented in the early seventies, their systems had become more of a hindrance than an asset. While these platforms could handle exceptional amounts of data, and perform extensive iterations, the ability to "get your hands on the information" was cumbersome at best, and frequently unrealizable. The question was, what would they replace them with?
Mainframes, the largest and most powerful general-purpose systems, are designed to meet the computing needs of a large organization by serving hundreds of computer terminals (dumb terminals, having no independent computing ability) at the same time. Minicomputers, though somewhat smaller, also are multi-user computers, intended to meet the needs of a small company by serving up to a hundred terminals. Microcomputers, computers powered by a microprocessor, are subdivided into personal computers and workstations (clients), the latter typically incorporating RISC processors (servers). Although microcomputers were originally single user computers, the distinction between them and minicomputers has blurred, as microprocessors have become more powerful. Linking multiple microcomputers together through a local area network or by joining multiple microprocessors together in a parallel-processing system has enabled smaller systems to perform tasks once reserved for mainframes.
As computers and their operating systems became more "friendly", smaller and less cumbersome, there arose the need for new software applications to perform likewise. After considering redeveloping the same technology and taking a spin on the late '80's custom-development-using-different-architecture bandwagon, companies finally decided that the future lay in client-server solutions. In many cases, years after recognizing the need, companies' -- much to the delight of software developers -- are now buying, not building software. Many companies today are spending huge amounts of money on enterprise, knowledge-based systems such as SAP®, Oracle® and PeopleSoft®. These integrated systems, for example, automatically update all the accounting records affected by a transaction. For example, when you record a credit sale to a customer, the system increases the amount the customer owes you, reduces the inventory for the item purchased, and records the sale so that it appears in your income statement. This requires updating the databases for accounts receivable, inventory, and the general ledger. In a non-integrated system you would have to enter the transaction three times, once in each database--a lot of extra work, and a good opportunity for error.
These systems, sold in modules, have caught the attention of CEO's based on the assurance of integrating the companies heretofore-unrelated operations. By promising to provide the benefits of better strategic planning, product development, materials purchasing and utilization, manufacturing, inventory management, distribution, customer service, and financial reporting, there comes the (inevitable) additional "benefit" of downsizing. Generally taking one to two years to implement, these client-server applications are catching on rapidly. Today, many software companies who produced very productive solutions over the last decade are now scurrying to re-write their applications on a user-friendly, graphically intense, Windows® based platform.
Which system is right for your business? There are no easy answers here because there are no perfect systems; each system has some strengths and some weaknesses. Selecting a package inevitably involves compromises.
The Accounts Receivable module of a company's business system allows the application and tracking of receivables and collections. Using this module should allow for important information to be stored for an unlimited number of customers and transactions; and should accommodate efficient processing of customer payments and adjustments.
At a minimum, the system should have these features and abilities:
Download this document (pdf format, 13k)
Copyright 1999 Credit Research Foundation
CREDIT RESEARCH FOUNDATION and the CREDIT RESEARCH FOUNDATION logo are the trademarks of CREDIT RESEARCH FOUNDATION. The other trademarks, service marks, and logos used on the Site are trademarks of CREDIT RESEARCH FOUNDATION or others. Nothing on the Site shall be construed as granting, by implication, estoppel, or otherwise, any license or right to use any trademark without the prior written consent of CREDIT RESEARCH FOUNDATION. The designations ™, ®, ©, SM or any other intellectual property symbols reflect registration and/or use in the context of United States laws as they relate to such intellectual property symbols.