Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

Summary

The interface between Databasics’ time and expense management products, and Lawson Activity Management   is the result of a joint development project.  The interface strategy is to define a “middle layer” of standard tables with fixed formats to which the “system of record” for a particular type of information writes its updates and from which the “consumer” of that information takes its updates.  Generally, Activity Management is the system of record for codes and Time and Expense, the systems of record for employee time and expense reports.

 

The use of these intermediate tables has a number of benefits.  Among them are:

·         Insulation from changes to the applications.  One product may be changed without directly impacting the other. So long as the system of record fulfills its obligation to “fill-out” the intermediate tables in the agreed-upon fashion, then the consuming application need not be concerned with “back-end” modifications.

·         Asynchronicity.  Updating does not require that the interfaced systems perform their tasks at the same time.  This means, for example, that preventive maintenance on one system will not cause a data transmission involving the other system to fail. Similarly, coordination is not necessary to avoid attempting an update during load peaks.

·         Ease of simulation and prototyping.  Because the applications only access intermediate tables, neither system must be there for the other to test import and export processes—the intermediate tables may be filled manually or by test scripting.

·         Simplification of multi-direction feeds.  Provision of updates to multiple modules can be accomplished through a single, central facility—the intermediate tables.

 

The interface supports a standard integration model identified later in this document. If clients implement this standard integration model there is no need for additional development effort. The standard integration effort would require the same tasks needed in any project; installation, training, configuration, prototyping and testing and end-user rollout.

Any client that wishes to implement an integration other than the pre-defined standard model will need to add to their project team either their own development resources or consulting resources to define and custom-code their changes to the standard model at their own expense. Databasics and Lawson resources can be used at the respective parties consulting rates to support any changes to the standard model.

The Lawson Databasics interface was designed so that Lawson could provide a full solution.  With that in mind, it was decided that a full solution included at minimum the Lawson HR and Financial Suites.  Therefore,

DATABASICS Time- requires Lawson General Ledger, Payroll and Activity Management.

DATABASICS Expense - requires Lawson General Ledger, Payroll, Activity Management, and Accounts Payable.

The data extraction/flow from Lawson into Databasics includes Employee information, Pay codes, and optionally Leave Balances. If a client does not purchase the Lawson HR Suite they can enter this data directly into Databasics.

The data load from Databasics into Lawson in 8.x was designed so that the data from Databasics would be passed to the ACBBTRANS file and be processed in the AC542 program where the processing logic accesses Payroll to get wage information and standard costs. If the client does not purchase the HR Suite they would need to setup AC Resources and load them into Databasics; then the data passed from Databasics would need to go into the ACTRANSREL file to be processed in program AC540.  AC540 validates resource information and uses standard costs maintained in AC.

Interface Specifics Overview

From the standpoint of the interface, Databasics’ data model consists of two major structures:  Organization and Work Breakdown.

Organizational Structure

DATABASICS Organizational Structure is comprised of the Operating Unit, Department, Employee, Function, and Location.   Also associated with Organization are Currency, Employee Types, Holiday, Vendor, Time Code (Pay Code), Time Code Validation Rules, and User Reporting Group elements.

The Operating Unit is the highest level within an organization.  Operating Unit can represent any type of cost center or company.  An Operating Unit is unique across the entire organization.  For example, Operating Unit may correspond to an organization’s "Divisions".   Operating Unit is a required level of the Organization Breakdown.

Operating Unit

Lawson Activity Management contains the master records for DATABASICS Operating Unit. In Lawson this is the Company, GLSYSTEM data element.   Databasics connects to the Lawson database through a utility called Remote Agent .  For example, the Lawson table GLSYSTEM, AC550 extracts data to intermediate table ACDBSYSTEM, which TEAim maps back by a V_DB_OPERATING_UNIT.  Then RemoteAgent loads/updates Operating Unit table in DATABASICS.

Department

Operating Units may be broken down into Departments.  Department represents an Employee’s administrative unit.   Department IDs can be duplicated across Operating Units.  For example, there can be an Accounting Department in each Operating Unit.  Each Employee is assigned to one department.  Lawson maps to Databasics’ departments through Lawson Accounting Units, GLNAMES data element.  AC550 extracts data to intermediate table ACDBGLNAME.

Location

The DATABASICS element Location is used to capture specific business sites or if specificity is not required, geographic or political consolidations.  For example, different work/business rules may apply per Location with respect to the length of the workday, weekdays verses weekends, etc.  Each employee is assigned to a default location, which can be changed during Time Entry on a per line basis.  Lawson 8.0.1 maps to HR Location, PCODES data element. This will allow ability to override the HR location field at time record entry.  Required for override of tax location for use with BSI tax locator feature in Lawson (drives tax calculation by location).  AC550 extracts data to intermediate table ACDBLOCATE.

Employee

Employee is the lowest level of the Organization Structure and as noted above, Employees are assigned to one and only Department.  This element is used to identify the actual users of the DATABASICS system.  Lawson maps to DATABASICS’ employee through EMPLOYEEà ACDBEMPLY.

Vendor

DATABASCS’s Vendor identifies time and expense reports from employees of outside organizations who are working under contract.  Rules and reports can be driven off of Vendor.  Lawson 8.0.1 maps to DATABASICS’s Vendor through ACEMPVEN → ACDBEEVEN.    Lawson interface does not support subcontractors or employees outside of an organization. The use of vendors for the Lawson 8.0.1 interface is strictly for paying internal employees via Accounts Payable.

Work Breakdown Structure
 

The standard interface supports these scenarios:

Scenario 1

  • Activity (the posting level) in Lawson mapping to DATABASICS WBS Level 1.

  • Account Category in Lawson mapping to DATABASICS WBS Level 2.

  • In this scenario, the Lawson HR Job Code and Shift Code can optionally be mapped to DATABASICS Level 3 and Level 4 respectively.

Scenario 2

  • Activity (levels 1 – 4) in Lawson mapping to DATABASICS WBS Level 1 – Level 4.

  • Account Category in Lawson mapping to DATABASICS WBS function.

Scenario 3

  • Activity (the posting level) in Lawson—varying levels and different activity groups—mapping to DATABASICS WBS Level 1 – Level 4.

  • Account Category in Lawson mapping to DATABASICS WBS function.

For both scenarios, Account Category is optional.  The entry of the Account Category is determined by a flag on the Activity Group.  If no Account Categories are interfaced to DATABASICS, the Account Category will default from the Employee Master (HR 11) when running the Lawson interface program AC542.

 

DATABASICS Table

7.2.2 Lawson Table

8.0.0.1 Lawson Table

8.0.1 Lawson Table

 

 

 

 

Operating Unit

GLSYSTEM

ACDBSYSTEM

ACDBSYSTEM

Department

GLNAMES

ACDBNAMES

ACDBNAMES

Main WBS

ACACTGRP

ACDBACTGRP

ACDBACTGRP

Level 1

ACACTIVITY

ACDBACTVY

ACDBLEVEL1 – ACDBLEVEL5

Level 2

*

ACDBACTCAT

ACDBACTCAT

Function Relation

*

ACDBBLRATE

ACDBBLRATE

Assigned Function

ACASSIGN

ACDBASSIGN

ACDBASSIGN

Location

*

ACDBPCLVL

ACDBLOCATE

Employee

EMPLOYEE

ACDBEMPLY

ACDBEMPLY

Pay Group

PRPAYCODE

ACDBPYCLS

ACDBPYCLS

Pay Code

PRPAYCODE

ACDBPYCLSX

ACDBPYCLSX

Pay Code Assign

PRPAYCODE

ACDBPAYCD

ACDBPAYCD

Vacation/Sick Balances

*

ACDBTABAL

ACDBTABAL

Time Records

ACTRANSREL

ACTRANSREL

ACDBTRANS

Export Timesheets/Expenses to Lawson 7.2.2 Activity Transaction Relation File (ACTRANSREL)

DATABASICS exports timesheets/expenses to Lawson in two ways:

  1. Direct link to ACTRANSREL:  Databasics exports the data to the Lawson interface table directly either using ODBC or Native drivers.

  1. File Export:  Databasics exports the data to an ASCII file to be later imported into ACDBTRANS.  This method is used when there is no direct connectivity to the Lawson database server.

ACTRANSREL


Field Name


User Name

Field Type
and Length


Description

Databasics Values

TRR-RUN-GROUP
Required

Run Group

Alpha
12 positions

A required key. A user-defined unique identifier used to group together a set of records to process selectively or concurrently.

Run Group and Sequence Number are the keys to the ACTRANSREL file. They should be used to group records for interfacing.

YYYYMMDDHHMM

TRR-SEQ-NUMBER
Required

Sequence Number

Numeric
6 positions

A required key. A user-defined unique identifier assigned to each transaction to be transferred into the Lawson system. If all other key fields are alike, this may be used so that no duplicates will occur.

Sequential Number

TRR-OLD-ACTIVITY
Required

Old Activity

Alpha
35 positions

A required key. This is the old activity or project structure to be associated with the Lawson activity. This is validated in AC29.1 (Activity Relationship) or AC10.1 (Activity).

Concatenation of WBS Level 2, 3 or 4

 

TRR-ACCT-CATEGORY

Account Category

Alpha
5 positions

A required key. Account categories are groupings of costs, revenues, or a combination of both used for reporting and inquiries for activities in the Activity Management system.  All transactions are posted to an account category within an activity.

To associate the account category with an activity or activity group, the account category must be valid in the ACACCTCATX file.

Custom value

TRR-POSTING-DATE
Required

Posting Date

Numeric
8 positions

The date assigned to the journal entry that determines what period and year the transaction (journal entry) will reside in after completing the Transaction Conversion process.

Supplied Posting Date

TRR-SYSTEM
Required

System Code

Alpha
2 positions

The system code is a two-character code representing an application used within the Lawson system (i.e., GL = General Ledger, AP = Accounts Payable, etc.). It must be a valid system code in the GLCODES database file.

Default value ‘PR’

TRR-COMPANY
Required

Company

Numeric
4 positions

Company number. Required if billable, capital expense, or if the activity group “Accounting Unit Detail” field is set to Yes.

Operating Unit

OP_UNIT

TRR-ACCT-UNIT
Required

Accounting Unit

Alpha
15 positions

The accounting unit is a shorthand notation representing the variable level number. The accounting unit must be defined in the General Ledger Names file as a posting accounting unit. Required if billable, capital expense, or if the activity group “Accounting Unit Detail” field is set to Yes.

Department

DEPT_CODE

TRR-ACCOUNT
Required

Account

Numeric
6 positions

This account field, the accounting unit and the subaccount make up the location where amounts and other account information are stored. Required if billable, capital expense, or if the activity group “Accounting Unit Detail” field is set to Yes.

User defined default value at the interface level

TRR-SUB-ACCOUNT

Subaccount

Numeric
4 positions

This subaccount field, the account unit, and the account make up the location where amounts and other account information are stored.

User defined default value at the interface level

TRR-DESCRIPTION
Required

Transaction Description

Alpha
30 positions (lower case)

Transaction description.

Last Name, First Name

TRR-REFERENCE

Reference

Alpha
10 positions (lower case)

Reference number associated with the transaction.

Space

TRR-UNITS-AMOUNT
Required

Units Amount

Signed
15 positions
(2 are decimals)

Units amount for the transaction. Required if TRR-STD-COST = Y.

Hours (VALUE)

TRR-TRAN-CURRENCY
Required

Transaction Currency

Alpha
5 positions

Currency for the transaction.  Required if TRR-TRAN-AMOUNT is not equal to spaces. If left blank, the company description defaults.

Employee Currency

TRR-TRAN-AMOUNT

 

Transaction Amount

Signed
15 positions
(2 are decimals)

The amount in transaction currency to be posted.

Derived – Hours * Employee Cost Rate

TRR-TRAN-ND

Transaction Number of Decimals

Numeric
1 position

The defined number of decimal positions used for the transaction.

User defined default value at the interface level

TRR-RUN-DATE

Run date

Numeric
8 positions

The date the transaction was posted to the general ledger.

System Date MM/DD/YYYY

TRR-RUN-TIME

Run Time

Numeric
6 positions

The time the transaction was posted to the general ledger.

System time HHMM

TRR-SOURCE-CODE
Required

Source Code

Alpha
2 positions

Source code is a two-character code assigned to a transaction to identify where the transaction was created.

Default value ‘PW’

TRR-MATRIX-CAT-1

Attribute 1

Alpha
12 positions

Attribute name assigned to a transaction to track additional information.

Three attributes can be defined per source code.

Default value ‘BILLING_ROLE’

TRR-MATRIX-CAT-2

Attribute 2

Alpha
12 positions

Attribute name assigned to a transaction to track additional information.

Three attributes can be defined per source code

Space

TRR-MATRIX-CAT-3

Attribute 3

Alpha
12 positions

Attribute name assigned to a transaction to track additional information.

Three attributes can be defined per source code

Space

TRR-MX-VALUE-1

Attribute Value 1

Alpha
20 positions

The value for attribute 1.

Three attribute values can be defined per source code.

Function Code

TRR-MX-VALUE-2

Attribute Value 2

Alpha
20 positions

The value for attribute 2.

Three attribute values can be defined per source code.

Space

TRR-MX-VALUE-3

Attribute Value 3

Alpha
20 positions

The value for attribute 3.

Three attribute values can be defined per source code.

Space

TRR-RESOURCE-TYPE

Resource Type

Alpha
1 position

Type of resource associated with the transaction.  Must be entered if TRR-STD-COST-FLAG = Y.

Default value ‘E’

TRR-RESOURCE-CODE

Resource Code

Alpha
10 positions

Resource code associated with the transaction. It must be a valid code in the ACASSIGN file.

Must be entered if TRR-STD-COST-FLAG=Y.

Employee Id

TRR-UNIT-MEASURE

Unit of Measure

Alpha
12 positions

Unit of measure for the transaction. Must be entered if TRR-STD-COST-FLAG=Y. It must be valid in ACUOM file.

Default value ‘HOURS’

TRR-STD-COST-FLAG

Standard Cost Flag

Alpha
1 position

Indicates whether standard cost is associated with the transaction. If set you Yes, the system searches for the standard cost assigned in the resource file first, then the resource class file, and lastly the resource.

If set to Yes, the amount field is zero. The system used the standard amount multiplied by the units to determine the transaction amount.

Default value ‘N’

TRR-BILLABLE-AMT

Billable Amount

Signed
15.2 positions

This field indicates the billable amount for the transaction.

Zero

TRR-BILLABLE-UNIT

Billable Unit

Signed
15.2 positions

This field indicated the billable units for the transaction.

Zero

TRR-SEGMENT-BLOCK

User Analysis Field

Alpha
103 positions

This field indicates the user analysis values included in the transaction.

space

 

  • No labels