QAD EE Business Relations

by Don Lindsey

With the advent of the EE versions of QAD, there is a new data element introduced to the familiar structure of SE. If you deal with the EE versions, you have had to come to grips with this new concept of the “Business Relation.” The new EE data structure now looks like:

  • Database
  • Domain
  • Share Sets
  • Business Relations
  • Entities
  • Site Location

Business Relations is a new element that ties the address data to various data structure elements in QAD. To get the most out of your data structures, you should understand how QAD’s Business Relation coding works and how the data compares with the data structure of SE.

Basic System Foundations

The basic system foundations of a QAD implementation follow the logic of system-wide data shared by all domains and entities and includes:

Business relations and address-related data, such as address types, corporate groups, currencies, rounding methods, languages, counties, states, and countries. Also included is address-related tax data such as tax zones, tax environments, tax classes, tax usage codes, and tax types.

Financial data, such as shared set codes, credit terms, invoice statuses, profiles, and Supplementary Analysis Fields (SAFs).

Security data, such as users and roles.

Administrative data define e-mail definitions and printers. Some EDI used for eCommerce can be set up in system data.

User interface information, such as labels, menus, messages, and look-up definitions, are defined for the system foundations. Most operational data are domain-specific. This includes the setup for items as well as most purchasing, sales, and manufacturing functions. Some financial data is also domain-specific, such as GL masks—which determine valid combinations of accounts, sub-accounts, cost centers, and projects—and accounting periods. Although business relations are generally shared system-wide, you can create business relations that are owned by a domain and accessed only from within that domain.

Entity-specific data belongs to a particular entity within a particular domain and includes employees, bank account numbers, period closing status, and accounting transactions (general ledger and sub-ledger transactions and balances).

In Financials, the transaction numbering is per entity. There are exceptions where entities can share numbering, for example, additional GL numbering. Some data can be shared among two or more domains. All the entities within a domain must use the same shared data, but entities in other domains can use this data as well. The data types included in shared sets are GL account components (accounts, sub-accounts, cost centers, and projects), customers, suppliers, daybook codes, and exchange rates. Profiles link specific data items in shared sets to other elements within domains.

Records Referencing Business Relations

Business Relation codes in this structure are designations used by the QAD data structure to identify any of 12 elements that relate address, tax, and contact data to such concepts as customer and supplier records. They are defined at the database level. This lets you maintain all address data in one function and then reference it in other functions that require address data, such as Banks, Employees, Entities, Customer and Supplier records.

This matrix lists the 12 elements of EE that require a Business Relation definition.

 

 

 

 

 

 

 

 

 


36.1.4.3.1 – Business Relation

The Business Relation is defined in 36.3.4.1. – Business Relation Create and is comprised of a series of tabs:

Business Relation Data
Address General Info
Address Tax Information
Contact Persons

Let’s walk through the various frames of the 36.1.4.3.1 – Business Relation and investigate the fields and options. Business Relations data is basically the header frame of 36.1.4.3.1 – Business Relation Create.

The header frame of 36.1.4.3.1 contains:

Business Relation Code – Name. This will indicate to users what the particular Business Relation number characterizes. This is where you define the numbering schemas or how the number/code is put together.

Search Name. The search name can be different from the name and is intended to assist in searching the database for similar or other Business Relations.

Second Name. The Second name gives the user a place to either elaborate on the Name or denote another name for searching.

Third Name. The Third Name gives the user another place to either elaborate on the Name. The Second Name or denote another name for searching.

Group Name. The Group name can be used to group Business Relations for reporting purposes. These codes are defined in 36.1.4.2 Corporate Group Create.

36.1.4.2 Corporate Group Create

This menu sets the Corporate Group Name in the header of the 36.1.4.3.1 – Business Relation Create.

 

Active – This click field indicates that the record is active.

Autonumbering

You can use your own designations or schemas for any of the 4 elements that require a Business Relation. Or, you can have QAD “auto number” the several elements that require Business Relations. If you are prone to a non-significant numbering schema, this is an easy way to approach numbers.

36.1.4.3.10 – Business Relation Autonumber Activate
27.20.4.1 – Customer Autonumber Activate
36.1.7.10 – Employee Autonumber Activate
27.20.3.5 – End User Autonumber Activate
28.20.1.10 – Supplier Autonumber Activate

36.1.4.3.10 – Business Relation Autonumber Activate allows you to, in essence, pre-number your Business Relations. One must be careful to understand the impact and associations on the 12 elements that require a Business Relation definition.

36.1.4.3.1 – Business Relation Create – Address Info

The Address information sets the static data for the Business Relation code. The other 12 elements that use these Business Relations draw their address information from the Business Relation.

 

 

 

 

The navigation in 36.1.4.3.1 – Business Relation Create is not like the navigation in SE versions. To input additional records, you must right-click and use insert a new row.

This brings up the more familiar [easier to use] window with pop up.

 

 

 

 

 

The following fields are in the address info Tab of the 36.1.4.3.1–Business Relation Create:
Address – 1
st Address Line 1 Data
Address– 2nd Address Line 2 Data
Address– 3rd Address Line 3 Data
Name – Name of the Address
Search Name – Additional Search criteria
Telephone – Phone number if known
E-Mail – Internet address
Internet – URL
Fax – Fax Phone Number
Format – After or Before
Temp – Temporary Address
County Code – County in Which Business Relation resides
State – where Business Relation resides
Country – where Business Relation resides
Type – 36.1.4.1.1 – Address Type Create
Lang – Language of Business Relation
Country Format
Chamber of Commerce

 

36.1.4.3.1 – Business Relation Create Address/Tax Usage

The Tax Frame is used to set the parameters for the Tax Environment. This Tax Information should be set according to our organization’s financial interpretation of Global Tax Management.

If you want to know more, you can read any of the “Global Tax Management User Guide_xxxxxx.pdf.”

 

 

 

 

 

 

 

 

 

 


 

36.1.4.3.1 – Business Relation Create – Address Info – Contact Persons

The Contact tab allows the identification of all individuals that reside at the address of the Business Relation. In today’s employment environment, it is good to make sure that this tab is current, which will require at least monthly updates and reviews.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


 

36.1.4.3.1 – Business Relation Create – General

The 36.1.4.3.1 – Business Relation Create general tab sets the fields for:

Language Code – Default Language

Domain Restricted – Restricted to a Domain

Internal Entity  – Primary Entity

Intercompany Code

Intercompany – Check Box

Customer/Supplier Compensation Allowed

Tax Report = Yes/No

Name Control – Name of Control

Last Filing = Yes/No

 


36.1.4.3.1 – Business Relation Create – Defaults

The Default Tab of 36.1.4.3.1 – Business Relation Create is used to set up the system SAF codes, SAF concepts, and SAF structure. These SAF codes will automatically retrieve data from operational transactions for reporting on the financial side of QAD EE.

The normal approach to the implementation and use of the SAF process is:

Step 1: Create a SAF concept and codes based on your need to track GL Transactions.

Step 2: Create a SAF structure and add concepts and codes, as appropriate.

Step 3: Link structure to GL accounts, cost centers, or a project SAF.

 


Business Relation Type Code in 36.1.4.3.1 – Business Relation Create address tab


The type code in the address info section of the address tab sets the type of Business Relation. This is extremely helpful in assisting the reporting and analysis of the financial transactions in the GL. The default for the Business Relation type is the Head Office. Each Business Relation must have at least one address record of this type. Other types can be used, such as End-user, that can be defined in 36.1.4.1.1 – Address Type Create.

 

 

SE Equivalent

The following records must also have the SE equivalent setup in the listed menus to make the records visible on the EE operations side:

2.1.1 – Customer Data Maintenance

2.3.1 – Supplier Data Maintenance

11.3.1 – End User Data Maintenance

 

36.1.4.3.2 – Business Relation Modify

You use the 36.1.4.3.2 – Business Relation Modify to adjust, modify, or change a Business Relation. This information is critical to your successful use of QAD. It should be accurate and timely. You can also use the 36.1.4.3.5 – Business Relation Excel Integration to make adjustments to Business Relation if you are comfortable with that process.

 

 

 

 

 

 

 

Business Relations are fundamental to defining many of the critical elements in QAD EE. Understanding how they work and what data is included will go a long way toward improving the use of your QAD EE system. Business Relation plays a big part in coordinating, minimizing, and enhancing the use of critical elements of our data structure

We at 32 Soft have recognized the critical nature and importance of Busines Relation and are developing a new Busines Relation Data Loader for EE  that helps you manage the 36.1.4.3.1 – Business Relation Create function easily and quickly. If you are interested or would like more information, please contact us.

 

Don Lindsey, CFPIM, CIRM is a knowledgeable Implementation Project Manager, Trainer and Business Analyst for all areas of QAD. He has been an implementation manager on several large, complex MFG/PRO projects, and has worked with the QAD system since 2007 in Manufacturing, Systems Management, Service & Support, and Finance. Don has a diversified background in a wide variety of manufacturing industries from Medical to Electronics to Industrial to Consumer Products. He has spoken for many years at the APICS Conferences, having taught in the APIC Certification program at California State University @ Fullerton for more than 20 years.