Understanding Implementation Issues

This chapter discusses:

• Implementation planning.

• Business unit structure.

• Customer structure.

• Business unit sharing.

• Customer groups.

• Entry types and reasons.

Implementation Planning

Getting ready for production entails a lot of planning. You must analyze your receivables requirements according to your business and organizational needs, review your current environment, and think about the changes that you can make now and in the future. Although you might decide to simply transfer your current receivables structure, you will find that PeopleSoft Receivables can provide new avenues for receivables processing and design.

Here are the high-level steps for implementing a new system:

1. Determine receivables requirements.

2. Configure PeopleSoft Receivables to meet your requirements.

3. Set up PeopleSoft Receivables tables.

4. Set up PeopleSoft security.

5. Set up PeopleSoft Receivables ChartField security.

6. Convert data from the existing system.

Determination of PeopleSoft Receivables Requirements

Consider the best way to map your new system to your existing business structures, practices, and procedures. Closely examine the way that your business operates, how organizations and subsidiaries are divided, and what your customer structure is like. Consider the level of reporting detail and aging criteria that you need to age customer accounts. Consider if the delivered functionality is sufficient for your business needs or if you need to specially configure the system. If special configuration is required, then you must decide to what degree.

Configuration of PeopleSoft Receivables to Meet Your Requirements

You must establish the business units and the various control tables that the system uses for processing. At this stage, you decide how many business units you need, what your customer structure will be, and what parameters you want the system to use for processing items, payments, reporting, and so on.

Setup of PeopleSoft Receivables Tables

Setting up the PeopleSoft Receivables tables can be divided into three phases: global, core, and additional. You set up tables to enable the system to support PeopleSoft Receivables features. Use PeopleSoft Enterprise Setup Manager to determine the order in which you should set up tables.

Setup of PeopleSoft Security

To establish security, you need to decide how your internal job functions relate to the functionality of the PeopleSoft Receivables application. Which pages must cash processors access? Which pages do collection managers need, and which pages does the management team need? PeopleSoft Receivables enables you to define page access according to job function.

Setup of ChartField Security for PeopleSoft Receivables Components

PeopleSoft ChartField security provides a flexible, rule-based approach to administer security at a data level. ChartField security is supported in PeopleSoft Receivables and across other PeopleSoft Financials and Supply Chain Management (FSCM) applications. The ChartField security feature prevents unauthorized employees and contractors from viewing and editing sensitive financial data by restricting access to data stored with specific ChartField values.

The primary features for ChartField security are:

• • Enforce security rules by user, role, or permission list.

• • Enable ChartField security for all products or selectively by product.

• • Enable or disable ChartField security selectively by component.

• • Define rules to accommodate end-user areas of responsibility.

• • Refine access rules by product feature or component.

• • Support super user access to minimize setup.

• • Define components as exceptions to override security rules.

See Securing ChartFields.

Conversion of Data From an Existing System

When you convert your receivables data from your existing system to the PeopleSoft Receivables system, you need to consider how much history to retain from the old system. The new system displays only as much information as you convert into it.

See Also

Performing Data Conversion

Enterprise PeopleTools PeopleBook: Security Administration

Enterprise PeopleTools PeopleBook: PeopleSoft Setup Manager

Business Unit Structure

In PeopleSoft Receivables, a business unit is an organization or a subset of an organization that is independent with regard to one or more accounting or operational functions.

Deciding how many business units to use and when to use them depends on how you want to report on and track the transactions within your organization. Before you can define business units and start entering data into the system, you need to decide how you want to retrieve information from the system. The way that you retrieve information determines how you set up the business units.

See Also

Defining PeopleSoft Receivables Business Units

Current System Structure

When you decide on the business unit structure, examine the structure in your current system. What types of organizational categories do you use? Do you use company codes, organization codes, and division codes? How do you categorize customers?

Consider how existing codes and IDs might map to business units. Determine if you can map existing structures to business units or if you need to modify existing structures.

In PeopleSoft Receivables, a business unit typically represents a grouping of customer balances. Suppose that an organization has multiple companies or subsidiaries within it. Each of those companies is run as a separate business with its own set of products and customers and its own set of rules for handling those customers from a receivable point of view. Consequently, you would set up separate PeopleSoft Receivables business units for each company.

Consider reporting requirements and maintenance of balances when you decide how to group receivables in a business unit. Familiarize yourself with what data is defined at the business unit level. For example, if you use one method to age a customer's open items in business A and another method in business B, you must handle customers in business A differently from those in business B. It would make sense to set up separate business units for business A and business B.

As you determine the optimal business unit structure for your organization, remember that in some circumstances you must set up multiple business units. If you do not, you will be restricted from using certain features.

You may decide to set up separate business units even if you do not need them for processing. For example, one department in your organization may handle a particular group of customer balances, and you may want to use a separate receivables business unit for those customer balances. You may want to group certain customers together for analytical reasons even though other customers may be processed the same way. You may want to maintain accounting control and balances at a lower level than that of the total organization.

General Ledger Distribution

You must associate each PeopleSoft Receivables business unit with a PeopleSoft General Ledger business unit. The association does not need to be one-to-one. You can consolidate multiple PeopleSoft Receivables business units under one PeopleSoft General Ledger business unit. However, you cannot split a PeopleSoft Receivables business unit to associate it with multiple PeopleSoft General Ledger business units. Consider general ledger distribution when determining how many business units you need.

Associating Receivables business units with a General Ledger business unit

If you use PeopleSoft applications for all financial business processes, typically the PeopleSoft Receivables business units are the same as the PeopleSoft General Ledger business units. You set up PeopleSoft General Ledger first and then set up PeopleSoft Receivables to mirror PeopleSoft General Ledger. If you use a different general ledger system, you may not use the business unit concept. In this case, think carefully about how you will distribute from PeopleSoft Receivables to your general ledger.

Customer Structure

A significant part of implementing PeopleSoft Receivables involves converting existing data. Before you set up customers, familiarize yourself with the options for defining customer structures.

To ensure that your customer setup and maintenance is as simple and non-redundant as possible, PeopleSoft Receivables stores customer information at the business unit level and at the tableSet level.

Business Units

PeopleSoft Receivables stores customer accounting and receivables information by customer within a business unit. This type of information includes:

• Customer's balance.

• Customer's open items.

• Amount the customer owes in each aging category.

• Payment performance indicators, such as average days late and day's sales outstanding.

The combination of a business unit and a customer ID determines where the system stores customer accounting and receivables information. Once you set up your business units, the system stores accounting and receivables data by customer within a business unit (or at a subcustomer level, if enabled). The Receivable Update Application Engine process (ARUPDATE) creates and stores this information.

TableSets

PeopleSoft Receivables stores a variety of identifying and descriptive customer information by tableSet, such as:

• Customer's name and address.

• Customer's credit profile.

• Certain processing options.

• Correspondence options.

• Team member (sales person) assigned to the customer.

Any number of business units can share customer information stored under a setID. With customer information keyed by setID, the advantages are similar to control tables keyed by setID. You enter the information once and then link it to as many business units as you want. Each of these business units can process invoices, payments, and other receivables transactions for the customer.

Business Unit Sharing

Business units can share certain customer information through setIDs. Consequently, you should consider how you are going to set up your customers to optimize processing in your organization. How much do you want to share data among business units? Are the business units separate organizations that need to maintain completely separate customer records, even if they share some of the same customers with other business units in the parent organization?

Does a particular customer exist in more than one business unit under the same customer ID? Do business units share customer information, such as name and address, or does each business unit have its own customer information?

Different organizations answer these questions differently. For example, suppose that organization X has two different business units that do business with Rambling Motors Company. Both business units want to maintain their own customer information on Rambling Motors, so they set up two different customer IDs, both referring to Rambling Motors. In this situation, the two business units would most likely have setIDs that correspond to the business units, and they would maintain completely separate records.

Other organizations may want to take advantage of the power of setIDs. For example, suppose that Rambling Motors account 100 does business with all 10 business units of organization Y. Therefore, organization Y may want to set up its customer information only once and share that data among all its business units.

Customer Groups

You may decide to divide some of your business relationships among separate customers in the system, yet still maintain reports and inquiries to capture customers as a group. PeopleSoft Receivables offers the following grouping methods so that you can maintain separate information for individual customers but combine customers when you need to evaluate your overall exposure to a large customer group or identify payment trends for a large conglomerate:

• Bill to, ship to, and sold to.

• Corporate.

• Remit from.

• Correspondence.

• Magnetic ink character recognition (MICR) ID.

• Dun and Bradstreet (D&B) number and other reporting or classification codes.

• Subcustomer levels.

See Also

Maintaining General Customer Information

Maintaining Additional Customer Information

Entry Types and Reasons

Items are individual receivables that make up a customer's balance. Organizations may refer to items in a variety of ways, such as invoices, obligations, open items, receivables, and documents.

PeopleSoft Receivables distinguishes between items (the receivables that comprise a customer's balance) and pending items (information in the system but not yet updated in the customer's balance). During the Receivable Update process, the system uses pending items to update customer balances, either by creating new items or by adding item activity lines to existing items.

An entry type categorizes the pending items that create or update posted items within the system. The Receivable Update process uses the pending items to create or update items and to maintain customer balances. Examples of entry types are invoices, debit memos, credit memos, payments, prepayments, on account payments, deductions, adjustments, and write-offs.

When a pending item enters the system, the Entry Type field defines the type of pending item that it is. An entry type can be qualified by an entry reason, which is a method of further categorizing pending items.

Some pending items, such as invoices and credit memos, enter the system from a billing system. You create others (for example, on-account payments and deductions) behind the scenes as the result of commands performed during online processing. When you apply a payment, for example, the system generates several different kinds of pending items each with its own entry type.

Some organizations can manage their receivables adequately with simple entry types and entry reasons; other companies require a more elaborate coding structure. The complexity of setup depends on how you run your business and the level of detail with which you track items.

See Also

Setting Up Entry Types and Reasons

Entry Type and Reason Use

In addition to the required entry types and entry reasons, you may need additional ones for:

• More detailed reporting.

• Further qualification of your aging.

• Accounting entry templates for distribution to the general ledger.

• Special customer history capabilities.

• Exclusion capabilities for customer statements, dunning letters, overdue charges, direct debits, and drafts.

Use of Entry Types and Entry Reasons for Reporting

Any report that summarizes the status of open items or that lists all activity from the system includes the entry type and associated entry reason. To distinguish between credit memos that correct billing errors and credit memos that are issued because of shipping damages, for example, you can qualify the credit memo entry types with appropriate entry reasons.

Carefully analyze the types of reports that you use to see what sorts of categorization you use in your existing system. When you implement the new system, you may want to refine the reporting by making it more detailed. Conversely, you may decide to streamline your reporting by using fewer entry types and entry reasons.

Use of Entry Types to Qualify Aging

In traditional aging reports, each column normally represents a time period, such as 0 to 30 days or 31 to 60 days. Some organizations include certain entries in the same column.

You may want to age everything by time periods except credit memos, for example, and have the system display credit memos in one column. To accomplish this, set up an entry type that describes the items that the system moves to a specific column.

Definition of Accounts Receivable Templates With Entry Types and Entry Reasons

When you enter a pending item into the system, you predetermine its accounting distribution: what it is going to debit and credit in the general ledger. You create an accounting entry template so that, when you create the accounting entries online (or when the system creates them during background processing), the system populates the accounting information. The details that are included in the template varies by entry type and entry reason.

Use of Entry Types and Entry Reasons to Track Customer History

PeopleSoft Receivables includes a customer history feature that calculates activity totals on a calendar basis. The entry type directs the system to accumulate a total. You might decide, for example, to track sales by month for each customer. You then specify which entry types and entry reasons to include in that category.

You might decided to track deductions by month, according to a certain entry reason. The Receivable Update process uses the entry type and entry reason combination to determine which categories to update.