BlueSeer Documentation

Version 6.7

Date: 2023-12-01
Table of Contents
1 Quick Installation Guide 1 ....................................................................................................................5
2 Quick Setup 2 ........................................................................................................................................6
Simple Business Scenario (jobshop, retail, mfg) 2.1 ...........................................................................6
Basic Service Order Scenario 2.2 .........................................................................................................8
Personal Finance Usage 2.3 ..................................................................................................................9
3 Navigation Codes 3 .............................................................................................................................10
4 Import Data 4 ......................................................................................................................................11
Execute SQL Code Data Import utility 4.1.1 .................................................................................12
5 Sales and Distribution 5 ......................................................................................................................14
Customer Maintenance 5.1 .................................................................................................................14
Customer Maintenance Prerequisite Setup 5.1.1 ...........................................................................14
Customer Master Record Entry (navcode: cusm) 5.1.2 .................................................................14
State/Province Setup 5.1.3 .............................................................................................................15
Customer Master Field Definitions 5.1.4 ......................................................................................18
Customer Ship-To Maintenance 5.1.5 ...........................................................................................18
Customer Contact Maintenance 5.1.6 ............................................................................................19
Customer Cross Reference Maintenance (navcode: cupm) 5.2 .........................................................21
Customer Item Price Maintenance (navcode: cprm) 5.3 ....................................................................22
Carrier Maintenance (navcode: carm) 5.4 .........................................................................................24
Terms Maintenance (navcode: term) 5.5 ............................................................................................25
Quote Maintenance (navcode: quom) 5.6 ..........................................................................................26
Order Maintenance (navcode: ordm) 5.7 ...........................................................................................29
Sales Order 5.7.1 ...........................................................................................................................29
Service Order / Service Quote (navcode: srvm) 5.7.2 ..................................................................36
Searching Orders 5.7.3 ..................................................................................................................43
Shipper Maintenance (navcode: shpm) 5.8 ........................................................................................44
Shipper From Single Sales Order 5.8.1 .........................................................................................44
Shipper by Bill-To / Ship-To (Multi – order and Non-Inventory) 5.8.2 ........................................45
Warehouse Transfer Order 5.9 ............................................................................................................48
6 Purchasing 6 ........................................................................................................................................49
Vendor Maintenance (navcode: venm) 6.1 ........................................................................................49
Vendor Maintenance Field Definitions 6.1.1 .................................................................................50
Vendor Item Cross Reference Maintenance (navcode: vdxm) 6.2 ....................................................52
Vendor Item Price Maintenance (navcode: vprm) 6.3 .......................................................................53
Purchase Order Maintenance (navcode: purm) 6.4 ...........................................................................54
Purchase Order Creation 6.4.1 .......................................................................................................54
Purchase Order Browse (navcode: purb) 6.4.2 ..............................................................................55
Purchase Order Update 6.4.3 .........................................................................................................55
Purchase Order Print 6.4.4 .............................................................................................................55
Receiver Maintenance (navcode: recm) 6.5 ......................................................................................59
7 Inventory 7 ..........................................................................................................................................61
Serialized versus Non-Serialized Inventory 7.1 .................................................................................61
Product Code Maintenance (navcode: prcm) 7.2 ...............................................................................61
Location Maintenance (navcode: locm) 7.3 .......................................................................................64
Warehouse Maintenance (navcode: wahm) 7.4 ..................................................................................65
 Item Master Maintenance (navcode: item) 7.5 ...................................................................................66
UOM Maintenance (navcode: uomm) 7.6 ..........................................................................................68
UOM Conversion Maintenance (navcode: uomc) 7.7 ........................................................................69
Work Cell Maintenance (navcode: wkcm) 7.8 ...................................................................................70
Routing Maintenance (navcode: roum) 7.9 ........................................................................................71
Bill Of Material Maintenance (navcode: bomm) 7.10 .......................................................................73
Cost Maintenance (navcode: roll) 7.11 ..............................................................................................76
Production Entry (Generic) (navcode: prod) 7.12 ..............................................................................78
Production Entry By Plan (navcode: prodp) 7.13 ..............................................................................79
Inventory Adjustments (NavCode: inva) 7.14 ...................................................................................81
8 Scheduling 8 ........................................................................................................................................82
Scheduler (NavCode: schm) 8.1 ........................................................................................................82
Navigating the Scheduler (NavCode: schm) 8.2 ...............................................................................84
Example of the Scheduler Usage 8.3 ..................................................................................................85
Miscellaneous Plan Maintenance (navcode: plan) 8.4 .......................................................................91
Forecast Maintenance(navcode: fore) 8.5 ..........................................................................................92
MRP Maintenance (navcode: mrpx) 8.6 ............................................................................................94
MRP Browse (navcode: mrpb) 8.7 .....................................................................................................98
Retail Replenishment (navcode: reor) 8.8 ........................................................................................100
9 Freight Management 9 ......................................................................................................................103
Freight Control (navcode: cfoc) 9.1 ................................................................................................103
Freight Order Maintenance (Carrier perspective) (navcode: cfom) 9.2 ..........................................104
Freight Order Browse (navcode: cfob) 9.3 ......................................................................................106
Freight Order / Driver Scheduler (navcode: cfow) 9.4 ...................................................................107
10 Finance 10 .......................................................................................................................................109
Chart of Accounts Maintenance (navcode: accm) 10.1 ....................................................................109
Ledger Calendar Maintenance (navcode: calm) 10.2 .......................................................................111
Currency Maintenance (navcode: curm) 10.3 ..................................................................................112
Exchange Rate Maintenance (navcode: excm) 10.4 .........................................................................114
Department / Cost Center Maintenance (navcode: depm) 10.5 ........................................................115
Bank Maintenance (navcode: bank) 10.6 .........................................................................................116
Tax Maintenance (navcode='taxm') 10.7 ..........................................................................................117
Tax (GSTIN) 10.8 .............................................................................................................................119
Trial Balance Report (navcode=trba) 10.9 .......................................................................................124
Income Statement Report (navcode=inst) 10.10 ..............................................................................126
Account Reconciliation (navcode=recon) 10.11 ..............................................................................128
Financial Transactions Overview 10.12 ...........................................................................................131
Accounts Payable Transactions (Procure to Pay) 10.13 ...................................................................132
Financial Transactions Example Scenario 10.14 ..............................................................................132
11 Quick Cash Management (Personal Finance) 11 ............................................................................137
Quick Cash Navigation (navcode: cash) 11.1 ..................................................................................137
Quick Cash (Buying Asset) 11.2 ......................................................................................................138
Quick Cash (Selling Asset) 11.3 .......................................................................................................141
Quick Cash (Expense Miscellaneous) 11.4 ......................................................................................146
Quick Cash (Expense Recurring) 11.5 .............................................................................................151
Quick Cash Browse (navcode: cashb) 11.6 ......................................................................................156
12 Engineering 12 ................................................................................................................................157
Engineering Change Maintenance (navcode: ecnm) 12.1 ................................................................157
13 Quality 13 ........................................................................................................................................158
 Quality Problem Report (navcode: qprm) 13.1 ................................................................................158
14 Human Resources 14 ......................................................................................................................159
Employee Maintenance (navcode: empm) 14.1 ...............................................................................159
Shift Maintenance (navcode: site) 14.2 ............................................................................................161
Time Clock Management and Maintenance (navcode: time) 14.3 ...................................................161
TimeClock Accounting 14.3.1 .....................................................................................................164
AutoClock Maintenance and Procedure 14.3.2 ...........................................................................164
TimeClock Code Maintenance (navcode: tima) 14.3.3 ...............................................................165
TimeClock Accounting Codes 14.3.4 ..........................................................................................165
15 Administration 15 ............................................................................................................................167
Class (Panel) Maintenance (navcode: panel) 15.1 ...........................................................................167
Menu Maintenance (navcode: menu) 15.2 .......................................................................................168
Menu Tree Maintenance (navcode: tree) 15.3 ..................................................................................169
Field Definitions: 15.3.1 ..............................................................................................................171
Site Maintenance (navcode: site) 15.4 .............................................................................................173
User Maintenance (navcode: usrm) 15.5 ..........................................................................................175
User Permissions Maintenance (navcode: uspm) 15.6 .....................................................................176
Printer Maintenance (navcode: prnt) 15.7 ........................................................................................177
Label Maintenance 15.8 ...................................................................................................................178
Address Labels (4x6) (navcode: lbla) 15.8.1 ...............................................................................180
Container Labels (4x6) (navcode: lblc) 15.8.2 ............................................................................180
Label File Maintenance (navcode: lblm) 15.9 ..................................................................................181
Cron Maintenance (navcode: cron) 15.10 ........................................................................................182
PKS Maintenance (navcode: pksm ) 15.11 .....................................................................................185
FTP and SFTP Maintenance (navcode: ftp) 15.12 ...........................................................................187
FTP Maintenance Field Definitions 15.12.1 ................................................................................187
sFTP authentication 15.12.2 ........................................................................................................188
Utility Services (run server classes as a Windows Service) 15.13 ...................................................191
16 API (BlueSeer) 16 ...........................................................................................................................192
External API Clients 16.1 ................................................................................................................192
API Maintenance Menu (navcode: apim) 16.1.1 .........................................................................192
API Log (navcode: apil) 16.1.2 ...................................................................................................194
Internal API Services 16.2 ...............................................................................................................194
Host Application Service (Jetty) 16.2.1 .......................................................................................194
Available API Services (Internal) 16.2.2 .....................................................................................195
Sales Order API 16.2.3 ................................................................................................................195
Work Order API 16.2.4 ................................................................................................................197
Shipper API 16.2.5 .......................................................................................................................199
Customer API 16.2.6 ...................................................................................................................201
Item API 16.2.7 ............................................................................................................................202
17 EDI 17 .............................................................................................................................................203
Quick Guide Chronological Steps 17.1 ............................................................................................203
Trading Partner Maintenance (navcode: edtp) 17.2 .........................................................................204
Partner Transaction Maintenance (navcode: edpd) 17.3 ..................................................................206
Structure File Maintenance (navcode: mpsm) 17.4 ..........................................................................211
Document Recognition Maintenance (navcode: eddm) 17.5 ...........................................................213
EDI Control File (navcode: edic) 17.6 .............................................................................................216
EDI Loader (navcode: edip) 17.7 .....................................................................................................218
EDI Log Browse (navcode: edil) 17.8 ..............................................................................................219
 EDI Mapping Mechanics 17.9 ..........................................................................................................220
Mapper Tool (navcode: map) 17.9.1 ............................................................................................221
Mapping Process 17.9.2 ...............................................................................................................223
Mapping Methods 17.9.3 .............................................................................................................229
EDI Processing (Auto Schedule) 17.10 ............................................................................................233
EDI Processing using the internal Cron Scheduler 17.10.1 .........................................................233
EDI Processing using OS native or 3rd party cron/schedulers 17.10.2 .......................................234
EDI Work Flow Maintenance (navcode=wkfm) 17.11 ....................................................................235
EDI Utilities 17.12 ...........................................................................................................................241
Utility: Filter Directory For Various X12 transaction types / partners 17.12.1 ...........................241
Utility: Simple File traffic utility with Append Option 17.12.2 ..................................................242
18 Custom Application Guide 18 .........................................................................................................243
Customization Overview 18.1 ..........................................................................................................243
Customization Example 18.2 ...........................................................................................................244
19 Appendix 19 ....................................................................................................................................252
Miscellaneous MySQL one-liners 19.1 ............................................................................................252

1 Quick Installation Guide

Note: You do not need java installed to run BlueSeer. The package comes with the openJDK
17 JRE enclosed within. The execution of BlueSeer is independent of other Java installations
you may have on the target PC or any environmental paths previously assigned.

To install the binary .exe version (SQLite) :

1. Download the .exe binary install from the Downloads section at blueseer.com

2. Double Click the downloaded .exe file (you may need administrator rights)

NOTE: You may encounter an invalid signing certificate dialogue. This is typical with most

Windows platforms. If so, there is usually a link provided within the dialogue box to override

the warning and install anyway.

3. Choose your specific language and accept the remaining default options... and click finish to

complete.

4. When finished, you should have a shortcut on your desktop and/or Start Menu to launch the

BlueSeer application.

5. The login and password are 'admin' and 'admin' respectively. Enjoy :)

You can send feedback to [email protected] for any comments, questions, or concerns.
Note: The sqlite version has all the functionality of the multi-user version (mysql), but it is intended
for single-user use only. For multi-user use, you will want to choose the MySQL version of BlueSeer.

ENJOY!

2 Quick Setup

The below instructions provide setup information for simple business scenarios. With these
instructions, you can set up your system in less than 10 minutes to achieve the usage of order entry,
invoicing, AR aging, payment application, inventory tracking, etc. These instructions can be used to
perform a quick setup of your installation to cover the most basic needs such as order entry and
invoicing or reporting of miscellaneous income and/or expenses. For more advanced setups such as
traditional manufacturing environments, see the detailed documentation.

2.1 Simple Business Scenario (jobshop, retail, mfg)

Perform the following steps in sequence:

1. Site Maintenance. Go to Site Maintenance Browse by entering 'siteb' in the navigational text-
box on the main menu-bar. Click on the flag for record with site code 1000. This will bring up
the site maintenance window. Change the Site Desc, addressing info, and logo file (if you have
one) to match your companies info. Leave the remaining fields as-is. Then click update. Note:
the logo file must be in the BlueSeer/images directory as is the default image file
BlueSeer/images/bs.png.
2. Item Maintenance. You can manually enter your items one at a time or you can import your
items from a text/csv file. To manually enter your item, go to Item Maintenance by entering
'item' in the navigational text-box on the main menu-bar. Click new and you will be assigned
an item number. The primary fields to complete depend on the nature of your business. For a
detailed description see the Item Master chapter below. However, if you are simply buying and
selling the same item in a retail scenario, update the following fields with the appropriate
values: Description, Sell Price, Purchase Price, and choose Class Code 'A' (again...if you are
retail based). All other fields can remain the same. Then click Add to commit the item to the
database.
If you would like to import your items from a text file, you can use the Master Data Import
utility to upload your items. For simple scenarios where all the defaults are accepted, you only
need to provide a comma delimited text file of item, description, and selling price. You can
enter these three columns in a spreadsheet and save it to a CSV file. Make sure you're delimiter
is not in the data. You can use any delimiter you like, ":,|", etc with comma "," being the most
widely used. After you have prepared your text file, enter 'load' in the navigational text-box.
Then choose the 'Item Master' in the drop-down selection box. Put a check-mark in the Data
integrity check-box field. This will effectively assign the default settings. Also, change your
delimiter to whatever you used for a delimiter..."," in most instances. Then click the 'Upload'
button. You will be prompted for the location of your import text file. Once you choose the
 file, it will automatically attempt to load the records in your file. If there are any errors, they
will be generated in the output for you to review. If the file successfully loads, you can review
your items be entering 'itemb' in the navigational text-box and running the item browse menu.
3. Customer Maintenance. Go to Customer Maintenance by entering 'cusm' in the navigational
text-box on the main menu-bar. Click new and you will be assigned a customer number. Enter
the Name and address information of your customer. You can leave the remaining fields as
assigned by default. Then click Add to commit the customer to the database.

That's it....you're done with the basic setup. You can further proceed to create your first
order/invoice by entering 'ordm' in the navigational text-box on the main menu-bar. Click new, choose
your customer in the selection box, enter an optional PO Number and then go to the Lines Tab (do not
click add...as you do not have any items assigned). In the Lines Tab, choose your Item Number, enter
a quantity, and click 'Add Item'. Then return to the Main Tab and click Add to commit your order. You
can then invoice this order by clicking on the invoice button in the same menu. This will commit the
invoice and close the order. You can choose to print an invoice or packing slip from the appropriate
print buttons in the same menu. You can review your aging accounts receivable (invoice due dates
versus payments ) and your financial accounts with navcodes such as arav and acba respectively. See
the documentation for more information. Enjoy! :)
2.2 Basic Service Order Scenario

Perform the following steps in sequence:

1. Site Maintenance. Go to Site Maintenance Browse by entering 'siteb' in the navigational text-
box on the main menu-bar. Click on the flag for record with site code 1000. This will bring up
the site maintenance window. Change the Site Desc, addressing info, and logo file (if you have
one) to match your companies info. Leave the remaining fields as-is. Then click update. Note:
the logo file must be in the blueseer/images directory like bs.png is.
2. Customer Maintenance. Go to Customer Maintenance by entering 'cusm' in the navigational
text-box on the main menu-bar. Click new and you will be assigned a customer number. Enter
the Name and address information of your customer. You can leave the remaining fields as
assigned by default. Then click Add to commit the customer to the database.

If you simply bill/invoice service work (non-inventory items), then you are done. You can now
create your service orders and invoice. If you have inventory items, review step 2 in retail scenario
section. You can further proceed to create your first order/invoice by entering 'srvm' in the navigational
text-box on the main menu-bar. Click new, choose your customer in the selection box, enter an
optional PO Number and optional remarks, choose 'order' in the Type drop down selection box and
enter your Service Item in the text-box. You can then enter a price and an optional quantity (typically
a value of 1 will suffice) and then click 'Add Item'. Once the service item has been entered click 'Add'
to commit the service order. You can then invoice this order by clicking on the invoice button in the
same menu. This will commit the invoice and close the order. To print the invoice, enter 'invb' in the
navigational text-box and click the flag beside the appropriate invoice number. You can then click the
print invoice button. Also, you can review your aging accounts receivable (invoice due dates versus
payments ) and your financial accounts with navcodes such as arav and acba respectively. See the
documentation for more information. Enjoy! :)
2.3 Personal Finance Usage

This is as simple as it gets. Perform the following steps in sequence:

1. Site Maintenance. Go to Site Maintenance Browse by entering 'siteb' in the navigational text-
box on the main menu-bar. Click on the flag for record with site code 1000. This will bring up
the site maintenance window. Change the Site Desc, addressing info, and logo file (if you have
one) to match your personal preference. Leave the remaining fields as-is. Then click update.
Note: if you use your own logo, the logo file must be in the blueseer/images directory like
bs.png is.

That's it....you're done with the basic setup. For personal finance usage, you will primarily be using
only two menus within the Quick Cash main menu. Enter the navigational code 'cash' in the text-box
on the main menu bar. This menu contains 5 panels that should meet all of your requirements for
reporting everyday transactions. The other menu that you will use is navigational code 'cashb'. This is
the reporting tool that provides information on the entries you made in the 'cash' menu.
For more specifics regarding the Quick Cash menus and detailed instructions, see the table of
contents entries for Quick Cash and review the subject matter in the Quick Cash chapter.
Some example usage of this scenario are people who want to monitor and track their expenses and
or miscellaneous income. Store owners, Job Shops, Religious organizations, non-profit organizations
and any other entity who has a need to track their expenditures and income will find this aspect of
BlueSeer beneficial.
3 Navigation Codes

Each menu has a navigation code that allows you to quickly access any given menu without having
to point and click through the menu hierarchies. For example, you can quickly navigate to the BOM
Maintenance menu by typing the navcode 'bomm' in the navigation text-box on the menu-bar as shown
below. As another example, you can quickly jump to the item master menu by typing 'item' in the
navigation text-box on the main menu-bar. The relevant navcodes for each menu can be seen in the
"navcode List" report under the Help menu. Not all menus will have navcodes (some are Menu
Links), but all maintenance screens and relative browse/reports will have a unique code.
4 Import Data

It is sometimes necessary to enter mass amounts of new master data into the system. This situation
can result from a fresh implementation or a new product line (with a large number of items). BlueSeer
offers a 'Mass Load' menu that will allow certain menus to be loaded from a well constructed import
file. This import file must match exactly the required number of fields and field types of the
appropriate menu you are attempting to load. The list of supported menu imports are :

▪ Item Master
▪ BOM Master
▪ Customer Master
▪ Customer Ship-To Master
▪ Customer Cross-reference Master
▪ Customer Price Master
▪ Vendor Master
▪ Vendor Cross-reference Master
▪ Vendor Price Master
▪ Inventory Adjustment
▪ Generic Codes
▪ Carrier Master
▪ Routing Master
▪ WorkCenter Master
▪ Order – Shopify
▪ Fullfillment – Shopify
▪ SQL Code

The Import Menu can be accessed by navigating to the Admin tab and clicking on the 'Master Data
Import' menu. Alternatively, you can access by entering 'load' in the Navigation Text-box on the main
menu bar. Figure 4.1 below shows the import master data screen.

The Master data import menu has a drop-down list of acceptable menus that can support import load
files. To determine the required format of the menu you wish to load, choose the menu option in the
drop down and click 'Define'. The definition of the fields including type and validation stance will be
displayed in the text box. The field delimiter to use defaults to the colon ":", but you can override this
by choosing a delimiter in the delimiter text-box. If your data files has a header row with column
names, you can choose to skip this row by checking the ignore header row toggle box.

Once you have created the appropriate import file for the appropriate menu, click 'Upload', and the
import file will be loaded into the appropriate menu. There is a toggle box labeled 'Menu Integrity
Override'. If this is checked, the system will load the file without any validation of foreign keys
required in other menus. THIS IS NOT RECOMMENDED. The validation is necessary to ensure
that fields within your import file that have an impact on other menus have the pre-defined values that
are already loaded in the system. For example, if you enter a UOM in your item master import load
that does not already have a UOM master record set up, then the integrity of the data between the two
tables has been compromised and subsequent processing programs will fail to process the data
accurately. We offer this override option only for convenience of demonstration and feasibility to load
items with unknown foreign keys. It is possible to load with the override engaged, and manually edit
the tables at the SQL level to engage the appropriate foreign keys, but this requires meticulous care and
the appropriate skill level.
With regards to loading the 'Generic Codes' table, there are certain standards that must be met
particularly when attempting to load records that are used by BlueSeer in drop-down lists for various
menus. For example, if you are wanting to load the 'states/provinces' for countries that have unique 3
char ISO codes, you must enter the 'code_code' field precisely as BlueSeer requires in the customer
master, vendor master, and other menus that use the 'state' drop-down list. In this example, code_code
must equal 'state' (lowercase). An example of a legitimate file would be :

state:KY:Kentucky
state:VT:Vermont
state:SC:South Carolina
state:someabbreviation:statename

Consult the Generic Codes chapter for more information regarding this topic and the appropriate keys
required for successful loading.
Note: As of version 6.3, the state codes (code_key) can be up to 30 characters and the state names can
be up to 50 characters (code_value).

4.1.1 Execute SQL Code Data Import utility

You can execute SQL code directly in the Data Import utility by choosing 'SQL Code' in the drop-
down list. When you select this value, the 'Execute SQL' button will appear. You can enter and non-
updating SQL statement (Select, Show, Describe, etc) to query the database directly. There are SQL
syntax differences between the sqlite engine and the mysql engine. An sqlite example of selecting all
item master records in the item_mstr table along with their column header names would be:

SELECT group_concat(name) FROM PRAGMA_TABLE_INFO('item_mstr');

select * from item_mstr;

Upon clicking the execute sql button, a new output text-area panel will appear with the results of the
query. You can click the clear button to remove the output panel.

The same query in the mysql database engine can be written as follows:

SELECT group_concat(COLUMN_NAME) FROM INFORMATION_SCHEMA.COLUMNS

WHERE TABLE_NAME = 'item_mstr';
select * from item_mstr;

This is a convenient method to print all the results of any given table to the output panel in comma-
delimited format. You can then cut and paste into a text file as desired.
Figure 4.1. Master Data Import Menu
5 Sales and Distribution

5.1 Customer Maintenance

The Customer Master is key to many of the subsequent operations within BlueSeer and is the
cornerstone of most of the functionality of the Order-to-Cash life cycle. Setting up the Customer
Master and it's dependent menus correctly will establish the necessary defaults in subsequent menus
such as order entry, shipper creation, and invoicing. A well-constructed customer master will reduce
data entry in many of these order-to-cash dependent menus that follow.

5.1.1 Customer Maintenance Prerequisite Setup

The following is a list of Maintenance screens that contain data that is used by the Customer
Maintenance Menu in the form of drop down selection options. These drop-down lists are populated at
start-up by selecting the appropriate master tables of each drop-down type. All of these drop-downs
have a default value pre-installed with the initial install of BlueSeer, and while you can use these
defaults, you will probably want to add or edit the existing values to match your needs.

 Account Maintenance
 Dept/Cost Center Maintenance
 Carrier Maintenance
 Terms Maintenance
 Bank Maintenance

5.1.2 Customer Master Record Entry (navcode: cusm)

To add a customer, Click on the Menu Customer Maintenance under Address | Customer Menu. The
Customer Maintenance screen will appear. You can also enter “cusm” in the navigation text box and
you will be forwarded to the Customer Maintenance menu screen. It is necessary to add a new
customer code that represents the bill-to association of this customer record. Each customer code is
unique. Therefore, only one customer code per bill-to record is allowed. An error will be generated if
an attempt to enter the same code for two different bill-to customer records.
The default customer code is a sequential number automatically generated by the application upon
clicking the new button. Alternatively, you have the option of entering your own customer code as
well. The customer control menu (navcode: cusc) governs the automatic code creation. Un-check the
auto-generate field in the customer control menu to stop the auto-generation of the code. You can then
enter a custom code of your choice.
To add a new customer code, simply enter the code in the Number text-box field. The customer
code can be any alphanumeric characters with a max character length of 10 characters. Enter all the
associated data in the appropriate text-boxes and/or drop-down lists. Once all the necessary fields have
been entered, click the add button to commit the customer master record to the database. A dialogue
box will appear indicated a successful addition or an error for any field validation issues. Note, it is not
possible to enter any ship-to code information or contact information until the customer master record
has been committed. The Ship-To and Contact information is relative to the customer bill-to code and
cannot be declared without association to a legitimate existing customer code.
Several fields are 'required' fields. Most of the required fields are drop-down lists, so it is necessary
to choose the correct drop down option. You must enter a valid account in the Account field. The
Account field represents the AR Sales account you wish to associate this Bill-To code with. This value
will be validated against the accounts that were entered into Account Maintenance under Finance|
Ledger Setup. The Cost Center is another validated text-box. The Cost Center must be a legitimate
value found in Department/CC Maintenance under the Finance|Ledger Setup Menu. A generic cost
center of 9999 can be entered if multiple cost centers are not required by your site. Code '9999' should
be available in Department/CC Maintenance as a result of the BlueSeer install. Figure 5.1.1 and 5.1.2
are screen shots of the customer maintenance screen before and after entering a new record.
Once you've entered a new Customer Master record, you can retrieve the record by one of two
options. You can enter the code directly into the customer code field and press enter. If a legitimate
code is entered, the record will be retrieved and the code field will become deactivated with a blue
foreground color). If you enter an invalid code, the code field will show red foreground text.
Alternatively, you can click on the search button with the magnifying glass icon. These button will
display a modal search box where you can enter text to search by a particular field dictated by the radio
button group. Figure 5.1.3 provides a screen shot of this modal box. You can search by code, name,
line 1 of the address, or zip code. You can simply press enter upon the modal box appearing (with no
text), and all records will appear. Clicking the Flag icon button will return the record you selected. You
can then proceed to review, update, or delete (in some cases) the retrieved record. Note: Some
maintenance screens will not allow you to delete the record from the Maintenance menu due to the
associated nature of other tables that are related to this record. You will need to use a special delete
utility to delete these type of records.

5.1.3 State/Province Setup

The State/Province drop down list on the customer master menu is controlled by generic codes
that you can enter for various state or provinces of specific countries that you may do business within.
The three character ISO standard code is recommended, and as a result, only the first 3 characters of
the generic code you enter will be placed in the drop down list. The US states are provided by default.
You can delete all US state codes by going to the customer control menu and clicking the 'remove us
states' button. To enter other state/province values, go the the Generic Code Maintenance menu under
the admin main menu or enter the appropriate navcode (navcode: genm). There are three fields of
interest here. key1, key2, value/description. The key1 field will always be 'state' for any
state/province/locality related entries. The key2 field is used for the state/province/locality abbreviation
code or value you want to see in the drop-downs. Any entries in the key2 field will be used in all
state/province/locality related drop-down boxes in all menus that have the state drop-down box. The
value/description field is arbitrary.
To enter a new state/province record, enter the value 'state' in the field labeled key1. Enter the
desired code in the key2 field, and enter a description (arbitrary) of the desired code in the
value/description field. Once this information is entered, click add to commit the record. This
state/province record will now be visible in all the drop down lists of the various menus that have the
'state' drop down list. Figure 5.1.4 shows the Generic Code Maintenance menu with a sample entry for
Geneva, Switzerland. Note: as of version 6.3, the state abbreviation codes can be up to 30 chars, and
the state names can be up to 50 characters. It is important to note that if you use data import to
import your customer addresses, the state code in the import file must precisely match the value in the
key2 field (abbreviated or otherwise) in Generalized Code Maintenance.
Figure 5.1.1
Figure 5.1.2

Figure 5.1.3
 Figure 5.1.4

5.1.4 Customer Master Field Definitions

5.1.5 Customer Ship-To Maintenance

To add a customer shipto record, click on the menu 'Customer Master' under Address| Customer
Menu. The Customer Maintenance screen will appear. All shipto records are assigned to a particular
billto record. Click one of the search buttons in the customer maintenance screen, and retrieve the
customer billto record that is the parent of the shipto record you wish to add. Once you have the billto
record in the customer maintenace screen, click on the 'New' button next to the 'ShipCode' text box in
the shipto address panel of the customer maintenance menu. This will enable the shipto address fields
for you to enter. Enter a unique code in the 'ShipCode' text box and then enter all relevant information
in the appropriate address boxes within the shipto panel. Once complete, click 'Add' in the shipto panel
to commit the new shipto record. You can then retrieve the newly added shipto record by clicking the
search button next to the 'ShipCode' textbox and retrieving the record you just entered. Figure 5.1.5
shows the customer maintenance screen for adding a new shipto code 'TEST' for Customer 'ACME'.
 Figure 5.1.5

5.1.6 Customer Contact Maintenance

To add a customer contact record, click on the menu 'Customer Master' under Address| Customer
Menu. The Customer Maintenance screen will appear. All contact records are assigned to a particular
billto record. Click one of the search buttons in the customer maintenance screen, and retrieve the
customer billto record that is the parent of the contact record to be added. Once the appropriate billto
record is selected, Enter the contact type, phone, contact name, fax, and email fields with the
appropriate information and then click the 'AddContact' button in the Contact specific panel of the
customer maintenance menu. A dialogue box indicating the addition of a new contact record will
appear. The new record will also appear as a row in the table at the bottom of the Contact Panel. There
is no limit on the number of contact that can be added. With each additional contact added, a new row
will appear in the table. To edit a contact record, click on the row within the table. Upon clicking the
row, the entry fields above will be occupied with the appropriate data. Edit the fields as necessary, and
click 'EditContact'. This will commit the new data to the record and refresh the table. To delete a
contact, the procedure is similar to the edit procedure. Click (highlight) the row within the table that is
desired to be deleted, and click the 'DeleteContact' button. This will remove the record from the
database and refresh the contact table. Figure 5.1.6 below shows the addition of a new contact record
for the 'ACME' billto code.
Figure 5.1.6
5.2 Customer Cross Reference Maintenance (navcode: cupm)
Customer part cross reference allows one to associate an internal item part number to a customer's
part number. This association is important for many customer specific menus within BlueSeer.
Creating customer cross references to the internal parts facilitates the automation of the order loading
process by creating a list of customer specific part numbers (and customer specific prices ...see
customer item price maintenance) when the sales order is created for a specific customer. This prevents
the manual entry of customer part numbers and customer prices. Correct entries in the customer cross
reference menu also facilitates loading orders automatically with the EDI module. Inbound EDI orders
from any customer typically have the customer's part number within the document, and it is necessary
to cross-reference this customer part number to the appropriate internal part number so that the order
can load successfully.
To enter a customer cross reference record, enter 'cupm' in the navigation textbox or go to
'Address'|'Customer Menu'|'Customer Xref Maint'. Choose the appropriate customer code 'CustCode'
in the drop down selection and then enter the customer item in 'cust item' textbox. Once the customer
item is filled in, press the 'tab' key to move to the internal item drop down list. Note: if there is no
cross reference previously established, a message will appear below the customer item field indicating
'Adding New Record'. However, if there is already a cross reference record for this customer code /
customer part number combination, then there will be a message indicating 'Record Exists'. The
other fields are optional to enter. Once the fields have been entered, click the 'Add' button, and the
customer cross reference record will be committed. A screen shot of the enter a new record in the
customer cross reference menu is provided below.

Figure 5.2.1
5.3 Customer Item Price Maintenance (navcode: cprm)
Customer prices for customer specific items can be created and/or edited in the Customer Part Price
Master under 'Address'|'Customer Menu'|'Customer Price Maintenance'. Once inside the Customer
Price Maintenance menu, choose the appropriate CustCode from the drop down list. If there are any
previously associated item/price records for this custcode, they will appear in the 'Applied' list. You
can click on these records in the applied list to show the price for any item within the list. To enter a
new record, choose the appropriate item in the drop down list and then 'tab' to the price field and enter
the price. The price must be in decimal format "#.##". Each price list is specific to the uom and
currency that is applicable. Choose the appropriate uom and currency for the item. Once you enter the
required fields, click 'Add' to create the associated price record. It will appear in the Applied list.
Discounts can be created and/or edited in the same screen as the Part Price records. Discounts can
be entered in Customer Part Price Master under 'Address'|'Customer Menu'|'Customer Price
Maintenance'. Once inside the Customer Price Maintenance window, choose the appropriate CustCode
from the dropdown list within the 'Discount Maintenance Window'. If there are any previously
associated discounts, they will appear in the 'Applied' list. To enter a new record, enter a unique key in
the 'key' text field. Then 'tab' to the percent field and enter the percent of the discount. This discount
will be applied to all orders for this customer at the line item level. The discount percentage must be in
decimal format "#.##". Once you enter the percent, then click 'Add' in the Discount Maintenance
window to create the associated discount record. It will appear in the Applied list. Figure 5.3.1
provides a screen shot of the Customer Price Maintenance screen.
Figure 5.3.1

Note that once you click 'add', the application will immediately commit the price (in green
background). If you choose the cust and item again..you will see the previously committed record in
the 'Applied' listbox. The record will be a delimited value that includes the item, uom, and currency.
See Figure 5.3.2.
Figure 5.3.2
5.4 Carrier Maintenance (navcode: carm)
Carriers (SCAC) codes can be created in Carrier Maintenance for any necessary carrier regardless of
modal transport (truck, rail, ship, etc). The Carrier Maintenance menu provides a limited number of
fields to maintain specific information about any given carrier. The associated fields to the carrier code
are typically informational only. The 'scac' code, however, can appear in shipper, invoice, and bill of
lading prints, and outbound EDI documents. These carrier records are available as drop down list
values in a variety of customer and vendor specific menus (customer master, order entry, receiving,
shipping, etc). To add carrier code, go to Carrier Maintenance under 'Address'|'Customer
Menu'|'Carrier Maintenance'. The choice of carrier code is arbitrary and can be up to a maximum of 8
characters. The carrier code should not be confused with the scac code. The scac code is typically not
arbitrary and is specific to the carrier. In many cases, creating your carrier code with the same value as
your scac code is good practice. Most scac codes are between 4 and 6 characters however. You can
add an additional description to the code to associate a name with the new record. After entering all the
associated fields, click the 'Add' button, and the carrier record will be committed. Once the record is
committed, it will be available in the various menus mentioned earlier that may have the 'carrier' drop
down list.

Figure 5.4.1
5.5 Terms Maintenance (navcode: term)
Terms of payment for customer orders are maintained in Terms Maintenance under
'Address'|'Customer Menu'|'Terms Maintenance'. Each terms code created has an associated number of
days before payment by your customer will be due. This due date is calculated from the invoice date of
the invoice applied to the shipment. The terms code can be any 8 character code of your choice.
Example codes are N30, N60 for net 30 days due and net 60 days due respectively. A descriptive field
is provided for more detailed explanations of the respective term code. Enter the code, description, and
number of due days applied to this code. For example, if the terms agreement is 30 days from day of
invoice, Enter "N30" for the terms code (or Net30 depending on your preference), a description, and
the integer 30 in the due days field.
Once the terms code is defined in Terms Maintenance, it can be chosen from a drop down selection
box in the Customer Address Master record. Typically, each customer has a fixed terms length which is
agreed upon before shipment(s). Choose the appropriate terms code for each of your customers and
apply in the customer maintenance screen. Once set in the customer master, any sales orders or
schedules for this specific customer will have the terms field automatically pulled from the customer
master and applied to the order. You do have the option to change the terms code per individual sales
order in the Order Maintenance screen. However, the default terms code for the initial order will be
pulled from the customer master.
An optional Discount Due Days can be applied to the terms code in Terms Maintenance. You can
offer a discount of whatever percentage you choose if the customer pays the invoice early. You can set
the number of discount due days for each terms code that you wish to apply a discount. If you do not
wish to apply a discount for early payment, then set discount due days to 0 and discount percentage to
0. As an example, if you wanted to offer the customer a 3% discount if they pay in 45 days instead of
60 days (which is their original due date terms), then set Due Days as 60, Discount Due Days as 45 and
Discount Percentage as 3%. Note: Set the discount percentage as a legitimate percentage and not as
the decimal equivalent. For example, enter '3' and not '.03' for the discount percentage. Do not enter
the percent sign. Figure 5.5.1 below shows the Term Maintenance screen shot.
Figure 5.5.1
5.6 Quote Maintenance (navcode: quom)
Quotes can be created using the Quote Maintenance menu. You can enter 'quom' in the navcode
text-box on the main menu bar or you can click the 'Order' parent menu and locate the Quote
Maintenance sub-menu within the drop-down. The Quote Maintenance menu allows you to create
quotes to your customers for both inventory and non-inventory items. It provides options to assign
global pricing, discounts, and taxes from a predefined selection of configured records in both the
Customer Pricing menu and the Tax Maintenance menu.
There are two types of quotes that can be generated. The most common quote is the 'discrete' quote.
This type of quote is a singular quote with specific singular pricing per item per unit quantity. Once
created, these types of quotes can be committed to a Sales Order (without double entry) to facilitate
transfer of quote to order. Once the quote is committed, the quote is closed and a new order will appear
in Sales Order Maintenance. The quote order number is assigned to the purchase order number in the
new sales order. You will need to alter the ship to information, ship date, and PO number as necessary
as a confirmation step of the newly created Sales Order. The other type of quote is the volume pricing
quote. This type of quote is used for items that have price brackets that depend on the quantity ordered.
This type of quote does not lend itself to Sales order creation since the actual quantity ordered is
unknown. However, you can commit the volume type quotes to the customer pricing tables once the
customer accepts the volume pricing quote. This will commit the volume pricing records for the
specific item to the customer pricing table. These records will then be available to the Sales Order
creation algorithm for price selection that depends on the ordered quantity. Both quote types can be
committed by clicking the 'commit' button. Once committed, the quote is closed for further editing.
You can still however print the quote and view the contents of the quote.
Both types of quotes are defined for a specific customer code. Therefore, you have to enter the
customer information in the customer master before creating the quote. The quotes are also specific to
site and currency with the default site and default currency being applied upon initial creation of the
quote. If you foresee the use of discounts or taxes in the quotes, you will need to create these global
records as well in their respective menus (see customer pricing and/or tax maintenance in this
documentation). You can, for example, create discounts that are based on geographical location in
Customer Pricing Maintenance and apply those discounts to the quote. Tax records can be predefined
as well and assigned to the quote for the target customer as necessary. Only one discount record and/or
tax record can be chosen from the respective drop-down lists in the quote maintenance screen. You
can, however, bundle discounts and/or tax records within a single record if multiple assignments are
necessary.
With regards to item pricing, a default pricing will be selected for inventory items based on any
records found in customer pricing for that customer/item association. This can be overridden by
choosing a pricing group in the appropriate drop-down list. Any pricing records previously defined for
the target pricing group will be selected for that specific item/group association. In absence of any
customer pricing records, whether customer or group specific, the price will fall back to the item master
selling price in the item master table, independent of either customer or group. You then have the
option of overwriting the price in the quote. The price you enter in the price field will be the list price
of the item. NOTE: if you change the value in the pricing group drop-down box and you already
have line items assigned in the detail table, the list prices will be re-assigned. You should assign
your pricing group, discount and tax codes before adding items to the detail table. Any discounts
applied per choosing a discount code option will be applied automatically and will be visible in the
overall total price of the quote. Any applicable taxes as assigned by the tax code drop-down box will
also be automatically applied to the totals. At the bottom of the Quote Maintenance user interface are
the summary fields for discounts, taxes, and total amount of the quote. Image 5.6.1 demonstrates the
Quote Maintenance menu. Image 5.6.2 shows a typical print of a simple quote.

Figure 5.6.1
Figure 5.6.2
5.7 Order Maintenance (navcode: ordm)
The Order Maintenance menu found directly under the 'Order' Menu contains the functionality to
add, edit, and delete sales orders. It accommodates two types of orders: 1) Discrete(spot) type Sales
orders and 2) Scheduled(blanket) type orders. A large number of fields within the order maintenance
are pre-defined based on information entered for other Maintenance Screens (example: customer/ship-
to master, customer specific part numbers, customer specific part pricing, etc). The following section
describes some of these prerequisite data setups that are necessary for efficient operation of order
entries.
There are several maintenance menus that need to be setup prior to creating a sales order. The
minimum setup prerequisite is the Customer Master bill-to and ship-to information. The procedure for
entering your customer bill-to and ship-to info can be found in the Customer Maintenance section of
the documentation. The customer item cross reference data and the customer item pricing data should
also be setup prior to creating an order for a specific customer. This setup is necessary to ensure that
customer part numbers and pricing (including relevant discounts) are applied in the drop down
selection fields without having to manually look up each line item specific information. Choosing a
part number in the drop down list should automatically establish the customer part number and the
correct pricing and discounts to be applied once the customer cross reference and customer item prices
have been established. Figure 5.6.1 shows the screen shot of the Order Maintenance Menu.

5.7.1 Sales Order

The primary method for entering a sales order is by using the order maintenance menu. You can
enter 'ordm' in the navigational text-box on the main-menu bar to enter the order maintenance screen or
you can click 'Order'|'Order Maintenance' on the main-menu bar. Figure 5.7.1 shows an example of
the order maintenance menu. Sales orders are typically discrete unique orders that have unique
purchase order number from your customer. Sales orders can be entered manually or can also be
created via EDI 850 transaction with your customer / trading partner is the EDI mechanics are setup for
the specified customer. The sales order will typically a unique PO, delivery date, and specific items
and quantities that are to be shipped as a single order.
To enter a sales order, you must have previously created a bill-to in customer maintenance. Clicking
'new' in the order maintenance screen will highlight the customer and ship-to drop down selection
boxes in red background (see figure 5.7.2). You must choose a Customer and optionally choose a ship-
to or choose <new> in the ship-to selection box to manually enter a new ship-to address. Entering a
new ship-to address in this manner will also create a permanent ship-to record associated with this
customer.
After clicking 'new' all of the relevant fields will become enabled for editing. The key field will be
automatically assigned a next sequence number that will be used as the sales order number. After
you've chosen your Bill-to / Ship-to combination, you have the options to enter in a PO (provided by
your customer), Ship Via (the carrier you choose), and a Due Date that this order is expected to ship
among other fields in the 'Main' tab. There is a remarks field as well to enter any remarks necessary to
support the order and is visible on subsequent documents such as packing slips and invoices. Note:
You cannot click 'add' at this time until at least one item has been entered. Figure 5.7.3 shows typical
usage of the Main Tab within the order maintenance menu.
Once the 'Main tab' information of the order has been established, you can now click on the 'Lines
tab' and enter the item level specifics for this order. The 'item number' drop down selection box is
assigned by default from any item defined in the item master as item code 'M' or 'A' (Manufactured or
Asset). If you have defined items in the item master they will appear in this drop down selection box
along with assignments of the Description and List Price as recorded in the item master. However, you
can override this default behavior by creating customer specific items and customer specific pricing. If
any customer specific items exist, they will be automatically pulled into the item number drop down
selection box as well as any auto assignment of any customer specific pricing. The customer specific
pricing will take precedence over item master pricing if customer specific pricing exists. See customer
xref maintenance (navcode=cupm) and / or customer price list maintenance (navcode=cprm) for the
menus to create these records and consult the documentation on the usage of these menus.
Once you've chosen your item, the description, default uom, list price, disc, and net price will
automatically be assigned from association of either item master default records or customer specific
records. You then need to enter a quantity and click 'Add Item'. This will record your item in the item
table as shown in Figure 5.7.4. You will also notice the summation of total lines, quantities, tax, and
amount at the bottom of the Lines Tab. Adding or deleting items from the item order table will update
the summaries at the bottom automatically.
You also have the option of entering summary discounts, charges, or taxes at the bottom of the Lines
Tab. These discount/charges are applied as a summary level adjustment and are 'in addition' to any
discounts/prices at the item level. These summary adjustments will be reflected in the Total amount of
the invoice and are displayed on the invoice print as well. To enter a summary adjustment, choose
either discount or charge in the drop down selection box, enter an appropriate description of the type of
charge/discount and the appropriate amount. NOTE: Depending on whether the type is charge or
discount will have an impact on the type of amount and the 'label' of the field (the label will change
from 'amount' to 'percentage' depending on which type was selected. If Discount is the type chosen, the
amount applied will be a percentage of the overall order. If the type is Charge, the amount will be flat
rate amount. For example, if you wish to add a discount to the summary of 10%, you would enter '10'
in the field labeled 'percentage'. This will apply a 10% discount to the overall Sales Order total
amount. If you would like to enter a 'charge' of $40 , then you would enter '40' in the amount field,
and a flat charge of $40 will be applied in addition to the total Sales Order amount.
Once you have entered all items for this sales order and any summary adjustments as necessary, then
proceed back to the main tab and click 'Add' to commit the order. Upon clicking 'add', the order will
commit to the database, and immediately be retrieved giving a status message of 'order has not been
shipped'. This indicates that you have created an order but have not shipped nor invoiced the order.
You can then choose to print the sales order to printer or save as a PDF as shown in figure 5.7.5.
In a simple business scenario, You have the option of immediately invoicing this order if the order
will ship complete. In these situations where you do not need to go through steps of creating a shipper
(because of partial shipment of the order), you can simply click the Invoice button in the bottom left
corner of the menu, and the order will automatically be invoiced. The status label will indicate that the
order has been invoiced and the order is now closed for further operation. The print invoice button and
the print packing slip button will be enabled to print the documents accordingly.
If your business requires a formal shipping process because of partial shipments or separation of
duties or delays in shipment processing after the order has been created, then you will want to create a
shipper from the sales order and invoice the shipper. See Shipper Maintenance in the documentation
section.
Sales Orders are typically for inventory ordering / invoicing. If you have a non-stock item or you
would like to invoice for a service you performed, go to the Service Order menu by entering the
navcode “srvm” in the navigational text-box. This menu is intended for more service oriented
order/invoicing schemes, but does allow for a mixture of service items and inventory items. See the
service order portion of the documentation for more detail on the subject.
Figure 5.7.1
Figure 5.7.2
Figure 5.7.3
Figure 5.7.4
Figure 5.7.5
5.7.2 Service Order / Service Quote (navcode: srvm)

The Service Order menu is intended for service oriented ordering/invoicing or situations where you
have non-inventory and inventory items mixed on the same order. This menu is ideal for individual
businesses or small companies that provide a service (lawn care, auto servicing, etc) in which an
invoice will be need to provide the customer with the details of the work complete as well as the total
cost (sales price) of the service. This menu also allows a quoting option to create quotes as necessary
and to convert quotes into legitimate orders. This service order menu is similar to the standard sales
order menu with only a few differences in navigation. The mechanics of this menu favor a business
model where a sequence of events are expected such as quoting, ordering, and invoicing in that order.
However, you can mix and match these types of service orders as necessary. The default behavior is
to create a quote, convert the quote to order, and invoice order in that chronological sequence.
The service order menu can be found by entering 'srvm' in the navigational text-box on the main-
menu bar. Similar to the standard sales order menu, you must have a customer previous set up in
customer maintenance in order to use the service order menu. To add a new service order and/or
quote, click the new button and choose the appropriate customer code. The job site selection box is a
drop-down that has possible job site locations associated with this customer code. Note: you can add a
new job site by going to (navcode='cusm') and entering a ship-to for the customer code in question.
Once you've chosen your customer and job site, you can enter an optional PO number and remarks.
The Type field defaults to 'quote', however, you can set this to 'order' if you wish to skip the quote
process and just enter a service order. Typically, you would create the quote, and subsequently use the
'QuoteToOrder' button to convert to an order upon successful agreement/confirmation of the quote by
the customer.
To enter detail into the service order, you must choose one of the two radio buttons of choice. The
button 'Service' will enable the service related text-boxes. The Inventory radio button will enable the
inventory related item selection boxes. You can mix and match these options as necessary. After
picking one or the other, click 'Add Item' to add the detail to the item table. Once you've entered all the
item detail necessary, click 'Add' at the bottom of the application to commit the order. Note: if you
left the type as 'quote', a quote record will be created, and the QuoteToOrder button will be higlighted
in yellow as shown in figure 5.7.8. Upon confirmation of the quote, you can click this button, and the
quote will be converted into an order to be processed. If you entered as type = 'order' and bypassed the
quoting process, the 'invoice' button will be enabled, and you can choose to invoice the order at any
time. The print button at the bottom will print a 'quote' if type = 'quote' and a service order if type =
'order' once the record has been committed.
With regards to entering service type items, the price entered will be the base price and subject to
the number of quantity/hour entered. For example, if you enter $45 in the Price field and a Unit/Hour
of 5, then the total price for that service item will be $225.00. Likewise for the Inventory type detail,
the total price is subject to the quantity multiplied by the unit price.
To see or print the invoices (or save to PDF) for these service orders, enter 'invb' in the navigational
text-box. You will be able to retrieve the invoices by date and bill-to for a range of invoices. Click the
'basket' icon to see the detail of each invoice/shipper. Click the 'flag' icon to enter the invoice detail and
print the invoice or save to a PDF as necessary. Figure 5.7.10 shows an image of the invoice print.
Figure 5.7.6
Figure 5.7.7
Figure 5.7.8
Figure 5.7.9
Figure 5.7.10
Figure 5.7.11
5.7.3 Searching Orders

To search for a specific order, click the search button (magnifying glass). This will prompt a modal
dialog box where you can enter text to search by order number, po number or customer code. Enter
text in the text field of the modal box, choose your field option, and press enter. If you want all
records, just press enter on the empty text box.t If records are returned, the browse screen will show
each record with a select flag button beside the record. Clicking on the select button will return you to
the order maintenance screen with the appropriate record selected.

Figure 5.7.12
5.8 Shipper Maintenance (navcode: shpm)
Shipper maintenance allows you to create a discrete shipper for one or more orders that you have
previously created. The Shipper Maintenance menu offers two convenient methods for establishing the
shipper. The first method assumes a single order / PO will be applied to the shipper. Choose the
single order toggle switch for this type of shipper. The other method assumes multiple orders are
applicable to the shipper or non-inventory stock type of shipment. Choosing the multi-order toggle
switch, you will then assign the bill-to/ship-to to the shipper and later apply as many orders of this bill-
to/ship-to combination as necessary on the shipper. Once the shipper is created, you can then print
packing slips and/or pick tickets for pack staging or inventory movement. Once the shipment is
physically complete and ready to be transported, the final action of confirming the shipper can be
executed, which essentially commits the sales to the ledger and accounts receivable aging.

5.8.1 Shipper From Single Sales Order

To add a shipper from a previously established customer sales order, go to the 'Shipping'|'Shipper
Maintenance' Menu. Click 'New' to initiate a new shipper. This will generate the next sequential
number and assign it to the shipper# text-box You will then choose the 'single order' toggle switch
which will enable the order drop down list while disabling the bill-to/ship-to drop down option. See
Figure 5.7.1 below for the 'single order' selection option.

Figure 5.8.1
Next, choose the appropriate order number in the drop down list that you wish to ship and click the
button with the green 'plus' icon next to the order field. This action will load the order header and all
open line item information into the shipper fields and shipper item table. If there are items in the
'Detail' window that you do not want, you can highlight that item (row) and click 'Del Item'.
Once you have all your line items added to the Detail Item Table, you can then adjust the Header
fields (ShipVia, Trailer, Remarks, etc) as necessary before adding the order. Once all Header and
Detail fields are complete, click 'Add' at the bottom of the menu and your shipper will be complete.
The entire menu will 'reload' with the newly created shipper, and the 'status' field will indicate that this
shipper has not yet been confirmed (in red text). You can now proceed to create a packing slip by
clicking 'Print Shipper' at the bottom of the menu. At this point, you have created a shipper, but you
have not invoiced this shipper. Once the shipment is ready for transport go to the 'Shipper'|'Shipper
Confirm' Menu to commit your new shipper to the books. You can then return to the Shipper
Maintenance screen where you can print an invoice as necessary. Once confirmed, the status will
indicate that the shipper is already confirmed (in blue) and no further editing or adjusting of this
shipper is allowed.

5.8.2 Shipper by Bill-To / Ship-To (Multi – order and Non-Inventory)

To create a shipper for multiple orders (and non-inventory), click 'New' button. Then choose the
'multi order' toggle switch which will enable the bill-to and ship to drop down fields while disabling the
single order drop down field. See Figure 5.7.2 for a screen shot of the selection process.

Figure 5.8.2

Once bill-to and ship-to are enabled, choose the bill-to and ship-to from the appropriate drop down
selection lists. Then click the 'plus sign' button to the right of the ship-to drop down list. This will
enabled the header and detail fields for data entry.
Click on the 'Lines' tab to enter order(s) and adjust the detail as necessary. To search for all open
orders for this bill-to/ship-to combination, click on the search button (binoculars) and a modal box will
appear. (See figure 5.7.3). You can search by item number or item description for any orders that are
open for this bill-to / ship-to combination. To see all open orders, just press enter in the text box
window with no text. If open orders are available, they will appear in the modal table. Click the flag
icon associated with the order / item relationship you want to apply to this shipper and the detail table
will be assigned with that specific order line item detail. You can adjust the quantities as necessary.
You can repeat this process for as many unique order / item combinations as you wish to apply to the
shipper. When you have all the items applied, click the main tab and click 'add' to commit the shipper.
You can specify the specific inventory location you wish to issue inventory from by selecting the
appropriate warehouse and location values from their corresponding drop-down selection fields. Also,
if the item that you have chosen to ship is marked as a 'phantom' in the item master AND you have
multiple bill of materials (BOM) records for this item, you can select which BOM id you would like to
relieve inventory by choosing the appropriate BOM record. This will relieve 'issue' the inventory of
the BOM items only, and the parent item will not show inventory movement as expected if the item is
marked as phantom. This is useful in scenarios where you do not want to create multiple customer
items and prices for a single item that may have variable structures. For example, t-shirts of various
sizes and colors typically have the same price. A finished good item called 't-shirt' can be created with
a single price, and then alternate BOM of this 't-shirt' can be created to relieve the appropriate
size/color of actual inventory without the parent item showing negative quantities.
After the shipper is created by clicking 'add', you can print packing slips at will for the newly
created shipper. Note: before the shipper is actually invoiced and recorded in accounts receivable, the
shipper must be confirmed, typically when the shipment is loaded on the transportation vehicle and is
about to be transported. To confirm the shipment, click the 'confirm' button to complete the process.
You then have the option to print the invoice from the shipper maintenance screen or go to the invoice
browse utility (navcode=invb) where you can print invoices as necessary. Once confirmed, the shipper
status will indicate that the shipper is already confirmed (in blue) and no further editing or adjusting of
this shipper will be allowed.
Figure 5.8.3
5.9 Warehouse Transfer Order

945

WH2
Stock Transfer

WH1

943 944
OrderType=DO 940
OrderType=SO
940

Production / Controller
Shipment
Site

Customer
6 Purchasing

6.1 Vendor Maintenance (navcode: venm)

To add a vendor, Click on the Menu 'Vendor Maintenance' under Address| Vendor Menu, or you can
enter 'venm' in the navigation text-box. It is necessary to add a new vendor code that represents the
remit-to association of this vendor record. Each vendor code is unique. Therefore, only one vendor
code per remit-to record is allowed. An error will be generated if an attempt to enter the same code for
two different remit-to vendor records. To add a new vendor code, simply click the 'New' button and a
next sequence number will be assigned as the vendor code. Note: It is possible to enter a non-
sequential sequence number by toggling off the auto-assign checkbox in the Vendor Control
Maintenance screen. If you choose to manually create a vendor code, the vendor code can be any
alphanumeric characters with a max character length of 10 characters.
Once the code has been entered, then proceed to enter all the associated data that is appropriate for
this vendor. Most of the drop-down selection boxes have default values assigned, but you can choose
provided values as necessary. Once all the necessary fields have been entered, click 'Add' to commit
the vendor master record to the database. A successful entry message will be indicated in the message
bar or a dialogue box will appear with any problems from the data entry. Figure 5.1 shows a screens
hot of the Vendor Maintenance Menu and associated fields.
Note, it is not possible to enter any contact information until the vendor master record has been
committed. The contact information is relative to the vendor remit-to code and cannot be declared
without association to a legitimate existing vendor code.
Once you've entered a new Vendor Master record, you can retrieve the record by clicking on one the
magnifying glass search buttons. These buttons will take you to a search menu where you can enter a
search string to find the exact record you are looking for. The string can be search by “Begins with”,
“Ends With”, or “Matches”. If you simply click the FindIt button with no string, it will return all
records. Each record in the search criteria is returned with a select button (flag image). Clicking the
select button will return you to the Maintenance screen from which it was called along with associated
data relative to the record clicked. You can then proceed to review, update, or delete (in some cases)
the retrieved record. Note: Some maintenance screens will not allow you to delete the record from the
Maintenance menu due to the associated nature of other tables that are related to this record. You will
need to use a special delete utility to delete these type of records.
Several fields are 'required' fields. Most of the required fields are drop-down lists, so it is necessary
to choose the correct drop down option. You must enter a valid account in the text-box labeled AP
Account. The AP Account field represents the financial ledger account you wish to associate this remit-
to code with. This value will be validated against the accounts that were entered into Account
Maintenance under Finance|Ledger Setup. The Cost Center is another validated text-box. The CC
must be a legitimate value found in Department/CC Maintenance under the Finance|Ledger Setup
Menu. A generic cost center of 9999 can be entered if multiple cost centers are not required by your
site. Code '9999' should be available in Department/CC Maintenance as a result of the BlueSeer install.
6.1.1 Vendor Maintenance Field Definitions
This is a list of various vendor maintenance related fields that warrant further description :
• Group (text-box) This field allows the vendor code to be assigned to a specific group or set for
reporting purposes. A collection of vendor codes belonging to a larger set. This field is
optional.
• Market (text-box) This field is also used for reporting purposes to conglomerate vendors into
an additional set other than 'group'. This field is optional.
• Bank (drop-down) This is the default bank code that is assigned during vouchering for any
accounts payable transactions for this vendor. Upon payment to vendor, this field defines the
cash account (associated with this bank record) that will be debited.
• Currency (drop-down) This is the default currency code used for this vendor for all purchase
transactions including vouchering and payment. Values in this drop-down field are defined in
currency maintenance.
• Carrier (drop-down) This is the default carrier used for purchase orders and receiving for this
vendor code. Values in this drop-down field are defined in carrier maintenance.
• Terms (drop-down) This is the default terms used for all purchases and applied payment
schedules for this vendor code. Values in this drop-down field are defined in terms
maintenance.
• Price Code (text-box) This field can be used to define a 'group' pricing code that can be
applicable for one or more vendors. If this field is defined with a code, any new purchase
orders created will look in the vendor price maintenance tables for price records associated with
this code. This will allow multiple vendors to be assigned the same price code for certain items
if desired. Note: if this field is defined, it overrides the price lookup by vendor code. This
field is optional.
• Discount Code (text-box) This field is reserved for future use.
• SalesRep (text-box) This field is used for informational use only It appears in various reports.
This field is optional.
• Tax Code (text-box) This field is reserved for future use.
• AP Account (drop-down) This is the default Accounts Payable account that will be used for all
GL transactions associated with this vendor code for the purpose of receiving, vouchering, and
payments.
• Cost Center (drop-down) This is the default cost center (dept) that will be used for all GL
transactions associated with this vendor code for the purpose of receiving, vouchering, and
payments.
Figure 5.1
6.2 Vendor Item Cross Reference Maintenance (navcode: vdxm)
You have the option to enter vendor specific part nomenclatures for you internal items. Most
vendors have their own naming convention for any given part, and you have the option to create cross
references of your vendor's part numbers to your internal part number naming scheme. For example, if
you have an item named 'partA' and your vendor identifies the same part as 'partV' then you will want
to create the necessary records in Vendor Item Cross Reference Maintenance. Each of these cross
references that you add will be vendor specific. For example, you can have the above cross reference
'partA' to 'partV' for multiple vendors where each reference is associated to a specific vendor code.
To enter a vendor cross reference record, go to 'Address'|'Vendor Menu'|'Vendor Xref Maint'.
Choose the appropriate vendor code 'VendCode' in the drop down selection and then enter the vendor
item in 'vendor item' text box. Once the vendor item is filled in, press the tab key to move to the
internal item drop down list. Note: if there is no cross reference previously established, a message will
appear below the vendor item field indicating 'Adding New Record'. However, if there is already a
cross reference record for this vendor code / vendor part number combination, then there will be a
message indicating 'Record Exists'. The other fields are optional to enter. Once the fields have been
entered, click the 'Add' button, and the vendor cross reference record will be committed.
The vendor item cross reference is useful throughout the purchasing process. When entering a
purchase order, the vendor specific part number will be automatically applied to the po line and will be
visible for ease of identification without having to manually enter it each time you enter a new line item
on the PO. The cross reference will also be visible on various reports and receivers during the
receiving process. See Figure 2.2 for a screen shot of the vendor cross reference maintenance menu.
Figure 2.2
6.3 Vendor Item Price Maintenance (navcode: vprm)
Vendor item price maintenance allows you to maintain a list of prices per item per vendor that can
be used during the purchase order process. You have the option of entering a different price at the time
of PO creation, or you can have the prices default from the vendor item price table for any item you
enter on the purchase order.
Vendor prices for your items can be created and/or edited in the Vendor Item Price Master under
'Address'|'Vendor Menu'|'Vendor Item Price Maintenance'. Once you enter the Vendor Pricing
Maintenance window, choose your VendCode from the dropdown list. If you have any previously
associated item/price records, they will appear in the 'Applied' list. To enter a new record, enter the
item in the item text field. Then 'tab' to the price field and enter the price. The price must be in
decimal format "#.##". Once you enter the price, then click 'Add' to create the associated price record.
It will appear in the Applied list. See Figure 2.3 for a screen shot of the Vendor Price Maintenance
Menu.

Figure 2.3
6.4 Purchase Order Maintenance (navcode: purm)
The purchasing module within BlueSeer is based on a simple discrete purchase order record. The
PO record is the cornerstone of the purchasing module, and it allows the receiving and vouchering of
receipts from vendors against these records. The business-use scenario for purchase orders is fairly
straight forward. A purchase order is created for a vendor to deliver specific items and quantities on a
specific due date at an agreed upon price. The purchase order is referenced during receiving of the
goods, vouchering of the receivers, and the subsequent payment of the voucher to the vendor.

6.4.1 Purchase Order Creation

To create a new Purchase Order, go to the 'Purchasing' | Purchase Order Maintenance menu or enter
'purm' in the navigational text-box on the main menu bar. Click the new button to generate the next
sequential PO Number that will be assigned to the Number text-box. All the other fields will be
enabled at this point. Then select the vendor associated with this PO and assign other header fields as
necessary (site, ship-via, remarks, etc). Once the header info has been entered, click on the Lines tab to
enter the line items that will be assigned to this purchase order number. Choose an item in the drop-
down selection-box labeled item. Note: The Vendor Cross Reference Menu and the Vendor Item Price
Menu must be set up prior to creating a Purchase Order if vendor specific values are to be used in the
creation of the purchase order. Otherwise, item master default values will be assigned. The item
drop-down list will be occupied with items based on the following conditions. If the purchase order
control table (navcode=purc) contains a check mark in the Vend Item Only Xref check-box, then only
items that have been pre-defined in Vendor Item Cross Reference Menu (navcode=vdxm) will be visible
in the item drop-down list. The Vendor Item Cross Reference Menu maintains a list of vendor specific
item numbers that are associated with Vendor codes. If the Vend Item Only Xref is un-checked, then
all items in the item master table will be visible in the item drop-down list. Any item of class (M, A, or
P) will be committed to the item drop-down list. To continue, choose the item number in the drop
down list. Choosing an item in the drop-down list triggers the assignment of associated fields. Then
vendor item number will be assigned if there is an appropriate record in Vendor Item Cross Reference .
The item list price field will be assigned from the item master purchase price field. If there are vendor
specific price records in Vendor Price Maintenance, these records will override the default item
purchase price assignment. The disc%, and net price fields are accordingly assigned with values pre-
set in the Vendor Price Maintenance menu. You can override these values in list price, disc%, and net
price as required.
The quantity field will initially be zero. You will need to enter the purchase quantity expected for
this PO for this item in the quantity field. Once a quantity has been defined and pricing has been set
click the add button above the details-table to commit the item record to the table. (Note: To remove
an item from the detail table, click on (highlight) the desired row in the table and click the delete
button. This action will remove the row from the table and from the PO record). Once all the desired
line items have been entered for this PO, go back to the Main tab and click the add button to commit
the PO. Figure 6.4.1 and (a and b) shows screen shots for the example of creating a purchase order
with pre-defined item master records.
It is also possible to enter a purchase order for service or non-inventory items. You can manually
enter a miscellaneous item number (non-inventory item) in the Item drop down list. You can then enter
the other item related fields manually since there will be no item master record to retrieve associated
description and price fields. It will be necessary to manually enter the list price and disc% (if
applicable) and then click the Lines-update button. Figure 6.4.1c shows the entry of a non-inventory
item into a purchase order.

6.4.2 Purchase Order Browse (navcode: purb)

You can search for purchase orders via one of two methods. In the purchase order maintenance
menu, click the search-button beside the number field. You will be prompted with a search dialogue
box where you can search by purchase order number or by the vendor that the purchase order is
assigned to. Choose the specific radio-button beside the choice of search criteria (number or vendor).
Note: the vendor choice searches by vendor number, not vendor name.
The other method to search for purchase orders is to use the purchase order browse menu (navcode:
purb). In the purchase order browse menu, you can choose by a range of purchase order numbers
and/or vendor numbers and the specific site the purchase order is assigned to. You can also choose to
show open or closed purchase orders. Clicking the run-button will generate available purchase order
records matching the criteria. You can click on the select-flag image in column one to retrieve that
specific purchase order and enter the update mode in purchase order maintenance menu. You can also
click on the basket-button to see the line items associated with the selected purchase order within the
browse window.

6.4.3 Purchase Order Update

Updating a purchase order involves similar steps as the addition of a new purchase order. Selecting
a purchase order using the search button will return you to the purchase order maintenance menu in
update mode. To update any of the header fields in the Main tab, simply adjust the required fields as
necessary and click the Main-update-button in the Main tab. However, if you are adjusting any detail
level information on the purchase order, you will need to first update the details table on the Lines tab
with the necessary changes. To do this, highlight the specific item you are adjusting in the details table.
This will set the appropriate fields with the values for that line item that has been chosen. You can
adjust any field (except the item itself) and click the Lines-update-button. This will adjust the values
for the selected record in the details table. You then must choose the Main tab again and click the
Main-update-button in the Main tab to commit the detail level changes to the database for this specific
purchase order.

6.4.4 Purchase Order Print

To print a purchase order, search for the desired purchase order and bring it up in the purchase order
maintenance menu. Then, click the print-button. If the appropriate purchase order is found, a new
window will appear with the PO information to be printed. From this panel, you can either choose to
print (which the printer dialog box will appear) or you can choose to save the document in PDF or
other format. You must manually close the window when you have either saved or printed your
document. The format of the PO print program is site specific and can be assigned and re-assigned in
the site maintenance menu under the admin master menu.
Figure 6.4.1a (Main Panel for Purchase Order Maintenance –header info)
Figure 6.4.1b (Lines Panel for Purchase Order Maintenance –line/detail info)
Figure 6.4.1c (Non-inventory item in purchase order)
6.5 Receiver Maintenance (navcode: recm)
The receiver maintenance menu is used to receive goods into inventory against an applicable
purchase order. An image of the receiver maintenance menu screen is shown below in Figure 6.5.1. To
enter a receiver, click the new button. A receiver number will be automatically assigned. Receivers
can only be created against a vendor and purchase order of a selected vendor. By selecting a vendor in
the vendor selection-box, the purchase order select-box will be occupied with open purchase orders
assigned to the selected vendor. Only purchase orders that are not closed will be available in the
purchase order selection-box. Once the appropriate purchase order is chosen, you must then select the
item that you are receiving from the item selection-box. The items are assigned to the previously
chose purchase order, and will only appear if the item on the purchase order has a non-zero 'open'
quantity to receive against. Closed line items of a purchase order will not be visible. After drilling
down and selecting the item you wish to receive, the remaining fields can be assigned as necessary.
The packing slip field is a required field. The value of the packing slip will be applicable during the
vouchering and payment process and is displayed on various reports. You will need to enter a value in
the quantity field for received quantity as well as serial and or lot number for traceability. The lot
number if a reference field only. Once you've entered (at a minimum) the quantity field and packing
slip field, click the add item button to insert the line data into the details table. You can then choose
another purchase order line item to receive against as necessary. Once you have all the items received,
click the add button to commit the receiver to the database.
The serial number field deserves special attention. If the overall system inventory control setting is
set for (see inventory control menu), then you must enter a serial number to register the received
inventory with a serial number and an optional expiration date. You can use an external numbering
system as necessary as long as the numbering scheme used is unique per item. The serial number must
be unique across all received inventory for each item. If you do not use an external serial number
generator, you can click the generate button to assign a unique serial number to this receiver. If the
inventory control setting is not set for serialized inventory, then the serial number will be a passive
value and not used to distinguish the inventory on-hand for the item. It will however be visible on
some reports.
Several detail fields are disabled for editing and are read-only fields. These fields provide
information relevant to the purchase order line detail of the item being received such as line number,
quantity on the purchase order (quantity ordered), previously received quantities against the purchase
order ((quantity received), price and cost. The price field is assigned in the purchase order. The cost
field is the standard cost of the purchased item and is set during the rolling of standard cost (usually
once a year). The cost field provides a measure of standard variance relative to the purchase order
price of the item, which can vary over time within a calendar year.
There is a toggle box in the upper-right corner of the receiver maintenance menu that will permit
auto-vouchering of the receiver. Most manufacturing procedures separate the duties of receiving and
vouchering. The vouchering process is typically done after the goods are received into inventory and
after the invoice from the vendor is received some time later. The process is a confirmation step of
what is being invoiced by the vendor to what was received during the receiving process. In general, the
separate vouchering step (voucher maintenance) usually vouchers multiple receivers at one time for
single payment purposes. However, if there is no separate process defined and confirmation is chosen
at time of receipt, then you can click the auto-voucher toggle box to voucher the receiver at the time of
creation of the receiver. To use this, you must check the box before clicking the add button to commit
the receiver.
Figure 6.5.1
7 Inventory

7.1 Serialized versus Non-Serialized Inventory

BlueSeer offers two inventory control methods that governs the movement in/out flow of inventory.
The inventory can be either serialized or non-serialized, and this is controlled by a setting in the
Inventory Control menu by check-box 'serialize inventory'. If checked, the inventory movement is
serialized. Otherwise, the inventory will not be distinguished by serial number.
If the inventory movement is serialized, any items issued or received into inventory is segregated by
a serial number. For example, if item 50000001 is either received into inventory via the Receiver
Menu of a purchase order or received into inventory by the Inventory Adjustment menu, a serial
number is required for the entry. The entry is record in the inventory master table for the combination
of that item, site, warehouse, location, and serial number. All inventory is unique (accumulated) per
the four keys (item, site, warehouse, and location) that it was entered, however, a fifth key (serial
number) is added when the inventory is serialized and therefore all inventory is unique (and
accumulated) by serial number. The benefit of a serialized inventory is that your item inventory is
distinguishable by serial number, and by association an expiry date since all entries with a serial
number receive an expiry date based on entry. The expiration date can be assigned upon receipt, or
calculated based on a fixed number of days added to the date of receipt. The fixed number of days is
assigned for each item in the item master. Item movement in and out of inventory and quantity-on-
hand (accumulation) is therefore traceable by both serial number and entry / expiration date.
If the inventory control value for serialized inventory is unchecked, then all inventory movement
and accumulation is governed by item,site,warehouse, and location only. Any serial numbers entered
into Receiver Maintenance, Production Entry, or Inventory Adjustment is ignored when storing the
inventory.
Note: All items are stored in inventory by a minimum of two keys (Item and Site) if all other
variables (warehouse, location, serial) is <blank> and serialized inventory is turned off. Depending on
the values of (warehouse, location, serial) and the Inventory Control setting, an item can have up to 5
keys that will make the inventory unique. The following combinations are possible:
1. (Item, Site)
2. (Item, Site, Warehouse)
1. conditions: warehouse <> “” and location = “” and serial = “” and serialized = false
3. (Item, Site, Warehouse, Location)
1. conditions: warehouse <> “” and location <> “” and serial = “” and serialized = false
4. (Item, Site, Warehouse, Location, Serial Number)
1. conditions: warehouse <> “” and location <> “” and serial <> “” and serialized = true

7.2 Product Code Maintenance (navcode: prcm)

The product code is a very important concept in blueseer because it controls the puts and takes of
most of the financial accounting information collected within the application. All transactions
essentially use the product code as a guide to control which GL accounts are targeted for any given
transaction. As such, great care and forethought should be given to setting up the product codes for
your products and the accounts that are associated with each product code. Product codes are typically
controlled and maintained by the finance department. The finance department usually has the most to
gain (or lose) with regards to proper (or improper) setup of the product codes.
There are 26 accounts that are associated with any given product code. These account types are
labeled in the product code maintenance menu. Great care should be taken to ensure that the
appropriate account is assigned to the correct field when adding or updating product codes. Inventory,
Sales, Costs of Goods Sold (COGS), Purchasing, Variance are all accounting buckets that are
controlled by the product code for each item that incurs a transaction. For example, any given item that
is ordered, shipped, and invoiced to a customer will have the sales account and COGS account (as well
as varous inventory accounts) adjusted per the product code of the item being sold. All items in the
item master, whether FG, RAW, or WIP are assigned a product code. This allows financial accounting
tracking of the items and materials as they are processed for any given transaction within the day to day
activities of the business entity.
To add a new product code, go to 'Inventory'|'Product Code Maintenance' and enter any 4 character
code in the “prodcode” field. See Figure 7.1.1 for a screenshot of the Product Code Maintenance
screen. The product codes are a maximum length of 4 characters (do not input spaces or tabs). Once
you enter the code, you will need to enter all 26 account fields with 'valid' accounts. You can review
your chart of accounts in Ledger Account Maintenance. You must enter a valid account for all
accounting fields in the product code maintenance menu. Once you have completed all the fields, you
can then click 'Add', and the product code and associated data will be committed. To edit a product
code, you can simply go to the product code maintenance menu and enter the product code in question
and click 'Get'. The fields will then be populated with the product code data. Once you've adjusted the
fields you desire, click the 'Edit' button to save your changes.
There is a system default product code “9999” that is used by the system for 'default' behaviour
when no product code is associated with various items. Do not delete this record code. However, you
will have to adjust one or more account field values if you have entered a customer chart of accounts in
the GL.
Figure 7.2.1
7.3 Location Maintenance (navcode: locm)
Location Maintenance provides a method to identify various physical locations within your business
where inventory is maintained or transferred. These location records can identify 'actual' physical
locations or represent a system holding category for inventory movement. The scheme for locations
and their hierarchy within a site is the following: Each Site can have multiple warehouses and each
warehouse can have multiple locations within it. So, defining a location in location maintenance
requires the identification of a warehouse to associate it with. See figure 7.2.1 below for a screenshot
of the Location Maintenance menu.
To add a new location ID, click 'New' in Location Maintenance. Then, enter a location code in the
location field. You will then choose a site and a warehouse within a site and click Add. Note: both site
records and warehouse records must be setup before you can enter a location.

Figure 7.3.1
7.4 Warehouse Maintenance (navcode: wahm)
Businesses that have a significant amount of distribution channels within their organization can
establish warehouse entities within their sites. The warehouse maintenance menu allows you to create
individual warehouse entities that are associated with each site. Each site can have multiple
warehouses. These warehouse records are used predominantly with the Distribution functionality
within BlueSeer which allows a business entity to maintain product levels at specific warehouses and
move/ship product from warehouse to warehouse or warehouse to customer.
To add a new Warehouse, you will first need to ensure that you have the appropriate site record
established. Each new warehouse created is assigned to a specific site. The available sites to
associated are visible in the Site drop down selection box. If there are no values in the selection box or
you wish to add another site, go to Site Maintenance menu and add as appropriate.
Once you have your site maintenance records established, click 'New' in the Warehouse Maintenance
menu and enter a warehouse 'id'. You can then enter a name and address information for your new
warehouse. Choose a site to associate this warehouse to. Then, click 'Add' to commit your warehouse
to the database. See figure 7.3.1 below for a screenshot of the Warehouse Maintenance menu.

Figure 7.4.1
7.5 Item Master Maintenance (navcode: item)
Items can be added to the item master via the Item Master Maintenance Menu. You can access the
item master menu by enter 'item' in the navigation textbox. You can also access the menu by choosing
the "Inventory" main menu and then go to "Item Menu"|"Item Master Maintenance" menu. Some of
the fields in this menu are merely descriptive, and some are used to categorize the items. However a
few of the fields have a broader role and may control the functionality and behavior of other modules
as they pertain to the specified item. The item number is by default automatically generated for you
upon clicking 'new'. You can alternatively choose to enter your own item as well. You will have to
uncheck the toggle in the inventory control menu labeled 'auto item number assignment'. This will
prevent the systems from generating the item numbers, and you can then enter your own nomenclature
for the items. Assuming you are entering your own numbers, to enter an item, simply enter a value in
the part number field (do not use spaces) and choose the "class code" for which this item belongs. The
class code governs whether or not the item is a manufactured item or a purchased item. There are only
two class options, "M" and "P". If the item you are entering is a manufactured item, choose "M". If it
is a purchased component (or raw material), choose "P". You can now click the 'Add' button, and the
item will be added to the item master table. If you click 'Add' without adjusting any other data fields,
you will have entered the item with 'default' attributes. However, you will probably want to enter
additional fields to assign the appropriate attributes to your item. You can either adjust the fields prior
to clicking the 'Add' button, or add the item and then use the 'edit' button to adjust the fields after the
item has been entered. You can retrieve the item by entering the item in the part number field. If
the item is legitimate, the foreground color will change to blue and the field itself will be deactivated
once the record is retrieved. This will populate the maintenance window with the previously assigned
attributes of the target item. If you enter an unknown item, the field foreground color will change to red
indicating that the item is unknown.
You can also review a list of the items in the item master or search for item that have previously been
added by clicking the "Item Menu"|"Item Master Search" menu under the Inventory main menu. You
can click 'Search' as is for a complete list of items, or you can enter the first couple of characters to
narrow the search before clicking 'Search'. A list of items based on your search will be shown, and you
can click the 'Select' button associated with the target item to view all the detail of the target item in the
Item Master Maintenance Window.
As indicated earlier, most of the fields in the item master maintenance screen are informational only.
However, there are a few key fields that need to be discussed. The Product Code selection box assigns
the appropriate product code to the item. Product Code Maintenance maintains the collection of
product codes to choose from. This menu must be previously addressed before any product codes will
appear in the product code selection box. The product code governs which GL accounts are chosen
during specific transactions for the target item. If you have multiple products that can be grouped due
to similarities in processes, markets, costs, etc., you will most likely want to add these items to the
same product code. At a minimum, it is recommended to create two product lines, one for purchased
items (raw components) and one for finished goods.
The "type" field in the item master menu is purely informational. The choices provided in the
selection box can be added (or deleted) by using the Generic Code Maintenance menu to add or delete
records with the "ItemType" code / key pair. For example, you can enter a new type called 'mytype' by
going to Generic Code Maitenance and entering 'ItemType' in the code field and 'mytype' in the key
field. When you go back to the Item Master screen, you will see a new option in the Type drop down
selection labeled 'mytype'.
The unit of measure drop down selection box currently only supports "EA". A maintenance screen
to support more UOMs is under construction.
Both the selling price field and the purchase price field are informational only. You can enter these
fields or leave them blank. These fields are generally used when the pricing is a simple specified price
regardless of group or discount pricing and it is helpful to have the price listed here when viewing the
other attributes of the target item. The actual pricing (whether it be customer or vendor pricing) is
applied in the appropriate menus. See for customer pricing procedures or <xref
linkend="vendpricemaint" endterm='vendpricetitle'/> for vendor pricing procedures.
The three cost fields (overhead, outside, and material) are of significant importance to purchased
items (item of class "P"). The "material cost" field must be populated with the purchase price of the
item. The material cost field is used by the costing module to roll up purchased item costs within a
finished good product, so it is imperative that a cost be entered into this field. If there is any overhead
or outside costs that apply to this purchased item, you can enter those costs as well in the appropriate
fields. These costs will also be rolled up into the finished good cost of any product that consumes this
purchased item.
Additional fields such as SafetyStock, MinOrdered, and LeadTime are used primarily by the
modules MRP and Scheduling. These need to be set accordingly for the target items. You can choose
to not submit the item to processing by MRP or Scheduling by unchecking the appropriate box.

Figure 7.5.1
7.6 UOM Maintenance (navcode: uomm)
The Unit of Measure (UOM) menu allows for the definition of alternate units of measure other than
the base unit of measure EA. This menu is used in conjunction with UOM Conversion Maintenance to
establish selling and purchasing of items in units of measure other than the base unit of measure as
defined in the item master. To define an alternate UOM, enter 'uomm' in the navigational text-box on
the main-menu bar. Click new, and enter a code for the alternate UOM and an appropriate description.
There is a 3 character limitation for code definitions. Once you've entered the information, click the
add button to commit the record. See Figure 7.5.1 below for example of adding an alternate UOM.

Figure 7.6.1
7.7 UOM Conversion Maintenance (navcode: uomc)
The Unit of Measure (UOM) Conversion menu is used in conjuction with UOM Maintenance to
establish alternate units of measure. To define an alternate UOM conversion, enter 'uomc' in the
navigational text-box on the main-menu bar. Click new, and enter the base UOM in key1. The base
uom is used in all inventory transactions for inventory movement. Enter the alternate UOM in key2.
Both key1 and key2 codes must be previously assigned in UOM Maintenance (uomm). Once the keys
have been entered, then enter the ratio of key1 value to key2 value respectively in their individual text-
boxes. See Figure 7.6.1 below for an example. The figure shows the entry of EA (each) to CT (carton)
conversion record with a ratio of 12 to 1 respectively. Once you've entered the information, click the
add button to commit the record.

NOTE: to use the alternate UOM in sales orders and/or purchase orders, you must also have a
customer/vendor specfic price list for the specific alternate UOM as well. For the specific item you are
selling/purchasing, you must have both a conversion record (from alternate uom to base uom as shown
below) and a specific price record for alternate uom defined in customer price master or vendor price
master...depending on whether you're creating a sales order or a purchase order.

Figure 7.7.1
7.8 Work Cell Maintenance (navcode: wkcm)

The Work Cell maintenance menu provides a place to designate labor and burden costs associated
with operations within your business. This menu is key to establishing the cost associated with day to
day activities incurred during the operational phases of production. Each operation within the life-
cycle of a finished good should be associated with a work cell. The work cell is a means to define the
cost of an operation. The work cell can be defined to be as discrete or generic as necessary depending
on the level of granularity necessary to capture the cost of the operation. For example, let's assume
that a machining company is producing a threaded bolt. The bolt is made from raw bar stock and
requires several operations (it is assumed) to produce the finished good bolt. Each of the mulitple
operations would be a defined within one routing code (See Routing Maintenance). Let's assume that
the threading operation is performed by a single operator who works in the 'threading' department and
has a base salary of $35 / Hour. The burden associated with this operation is expected to be $15 /
Hour. Note: in this instance, burden is defined as any non-labor and non-material cost associated with
running the business divied up by department (work cell). In this instance, we have concluded that the
burden cost associated with this operation should be $15 / Hour and is thus assigned to this work cell.
Now that we have labor and estimated burden cost, we can define the work cell for this operation.
Figure 7.7.1 shows the screenshot of the creation of this work cell with these variables.

Figure 7.8.1
7.9 Routing Maintenance (navcode: roum)
Routing codes define the operations that an item will undergo during it's life cycle. The number of
distinct operations within the manufacturing of an item depends on how much detail you require in the
cost 'description' of the item. For example, the drilling and threading of a screw can be broken down
into two distinct operations, drilling as the first operation, and threading as the second operation. Each
operation will have it's own 'run rate' i.e. how many parts can you 'drill' in one hour and other relevant
information associated with that specific operation. In turn, each operation will also have a labor rate
and/or burden rate associated with that specific operation. On the other hand, you could combine both
operations into one operation with a summed value of both operational costs..i.e. summed labor and
burden costs and cumalative run rates. However, it is generally good practice to break up the
operations into distinct cost cells with unique run rates. This allows for improved cost analysis, better
metrics of operational efficiency, and identification of bottlenecks and throughputs. In general, the
more discrete reporting points the better.
Routing codes are a 'one-to-many' concept. Each routing code can have multiple operations (and
often do). For example, you could have routing code "MYCODE" that has operations A,B,C or
10,20,30. Each operation within the routing code will detail the labor, burden, and overhead cost
associated with that operation. The sum of the operational costs will be the cost of manufacturing the
item less the material cost and any outside service cost associated with the item. The cost of each
operation depends on the work cell (see <xref linkend="workcellmaint" endterm='workcelltitle'/> ) that
this operation resides in. The combined information from both the routing code maintenance and work
cell maintenance menus define the labor, burden, and overhead cost of the item.
Note: The work cell records must be set up before creating any routing code records. Likewise,
Both work cell codes and routing codes (in that order) must be created before creating any items of
type "M" (manufactured). This sequence of events ensures the proper information is assigned before
cost roll is applied to any items marked as 'manufactured'.
To add a routing code, first make sure you have already created the necessary work cells in the Work
Cell maintenance menu. Each routing code can have multiple operations at various work cells, so it is
imperative that work cells are defined prior to creating a routing code. Work cells are validated in the
process of adding a new routing code. Once you have established your work cells, go to
'Inventory'|'Routing Menu'|'Routing Code Maintenance'. Enter a routing code of your choice. In the
operation drop down box, enter an operation code for your first operation. For example, your routing
code can be 'testroute' and your first operation can be '10'. Then choose the work cell and machine (if
applicable) that this first operation resides in. Next, enter the setup hours required to setup this cell to
perform the first operation (example 1 hour setup time). Enter '0' for no setup. Then, enter the number
of pieces per hour this cell/operation can perform. You will notice that the 'run hours' to the right of
'pieces per hour' is automatically calculated based on your entry in pieces per hour. Once this
information is entered, you can click 'Add' to add the new routing code with it's first operation. To add
more operations, simply enter the same routing code and enter a second operation code (example:
routing code 'testroute' operation: 20). You will repeat this step of 'adding' operations for as many
operations with the routing code 'testroute'. Figure 7.8.1 shows a screenshot of the routing code
maintenance menu.
The 'Auto Backflush' check box in the routing code maintenance menu is of particular importance
and is used to define whether or not the specific operation within the routing code is reportable or non-
reportable. When you manufacture an item at a specific operation, you must either report that
operation as complete (Auto Backflush toggle=checked) or allow the system to automatically report it
when a subsequent 'reportable' operation is complete. (See production and scrap entry menus). The
last operation should always have it's Auto Backflush box checked. For example, suppose you have
five operations, 100, 200, 300, 400, 500 and we set both 200 and 500 as Auto Backflush
toggle=checked. In this scenario, you do not have to post production at operations 100, 300, and 400,
but you do have to post production at operations 200 and 500. When you post production at 200, the
system will automatically post production at operation 100. Similarly, when you post production at
500, the system will 'backflush' operations 300 and 400. The system will always backflush (on your
behalf) all previous operations that are not marked backflush...up to the most recent reportable
operation which in this case was 200. All operations within a routing code, once posted, will provide
visiblity of inventory movement and financial cost absorption. Therefore it is imperative that either
you post production (or scrap) for each operation or you allow the system to post on your behalf. The
final operation should always have Auto Backflush check box checked.

Figure 7.9.1
7.10 Bill Of Material Maintenance (navcode: bomm)

Bill of Material (BOM) is a phrase used to describe the components that comprise a finished good
(FG) item or a work in progress (WIP) item. The components that make up the FG or WIP item are
maintained in the Bill of Material Maintenance menu. In order to establish a BOM of a FG or WIP
item, it is first necessary to make sure that FG or WIP item is defined in Item Master as well as any
components that are included. All components must be defined in the item master as well before
including them in the BOM of an item. Furthermore, the parent item that is to have the BOM must
have a routing defined in the 'routing' field in the item master. This is necessary to establish the
operations where the BOM components will be consumed. At a minimum, every FG or WIP item that
is to have a BOM must have at least one operation within a predefined routing code (See Routing
Maintenance). Once these pre-requisites are established, you can then proceed to create the BOM of an
item. The creation of a BOM for an item will change the 'actual' cost of the item, but not the standard
cost. The actual and standard cost of the item can be viewed in the 'cost tab' of the item master
maintenance menu of the parent item in question. You will notice that establishing a BOM or changing
the BOM of a parent item will change the actual cost of the item. The standard cost will only change
once you roll the standard with the Cost Maintenance Menu under Inventory → Item Menu → Cost
Maintenance.
To add a BOM component to a parent item, go to the BOM Maintenance menu under Inventory →
BOM Menu → BOM Maintenance. Enter the parent item in the appropriate field. This field is
validated against the item master, so this parent item must be a record in the item master table. Note:
The parent item must 1) be of class code 'M' and 2) have a routing created and assigned to the parent in
the item master. You can choose the 'default' routing code in the item master for the parent if you do
not have a specific routing code.
If you enter/choose a legitimate parent item in the item master field (but without a routing) the
foreground color will turn red. If you enter/choose a legitimate parent item with a legitimate routing
and this is the first BOM created for this item, you will receive a message 'no BOM found for this
item'. You can then proceed to associate a child component item to this parent item. For the first
record, you must assign a BOM id. The BOM id allows for a parent item to have more than one bill of
material. Click the '+' image beside the BOM id. For the first record, the parent number is used as the
default BOM. Once the default BOM id is assigned, you can proceed to add components to this parent.
Choose the component from the list of items in the component drop down selection box. Note: All
items in the item master 'except' the parent item will be available for choosing in the selection box.
Once you choose the component, then enter the 'qty per' field with the quantity of this component that
will be consumed by this BOM. Then, enter the operation where this component will be consumed. As
mentioned earlier, the parent item must have a routing defined in the routing field in order for the
operation drop down selection box to have operation numbers available. You can then enter an optional
reference text note. Once all fields are correctly entered, click the 'Add' button to commit this
component to the BOM of the parent item. You will repeat this process as necessary for each
component that is needed to complete the parent item. See Figure 7.9.1 for a screen shot of the BOM
Maintenance menu.
Once you have the parent item's BOM structure complete, you can set the standard cost of this
newly created structure by clicking on the 'Roll Cost' button within the BOM Maintenance menu. This
should be done whenever you first establish a parent item or when you make significant change to a
parent item's structure.
 You can create BOMs with multiple depth levels by adding a WIP item as a component of the parent
item. This WIP item will have it's own BOM, and therefore the BOM tree will show a multi-level
structure to the parent item. WIP items are unique in that you should always ensure that WIP items
have their cost rolled (as a parent) before including them in the BOM of a parent. Note: for new parent
items, you should always roll standard once the entire BOM is complete.
To Update a BOM, choose the parent item in BOM Maintenance, and then choose the appropriate
BOM id of that parent item by clicking the search box beside the BOM id text-box. You can then
update any component item on the parent 'tree' by clicking on the appropriate component item within
the tree structure window. The event of clicking the component item will retrieve this specific
parent/child record association and you can then proceed to update the qty-per, operation, and reference
fields as necessary. Click 'Update' when your changes are complete. This will update this record with
the new values and the tree structure will automatically adjust in the view. Note: Once you update a
BOM record, the actual cost of the parent may change depending on the nature of the update. The
standard cost of parent will not change until you roll cost in Cost Maintenance or by clicking the 'Roll
Cost' within the Maintenance menu window.

Figure 7.10.1 BOM Maintenance Menu (before 'add' of child to parent)

Figure 7.10.2 BOM Maintenance Menu (after 'add' of child to parent)
7.11 Cost Maintenance (navcode: roll)
Standard and actual costing are the only cost methods supported within BlueSeer as of this version.
There are several maintenance screens that must be set up to correctly apply standard costing, however,
most of these menus are generically applied to many items and once created, are applicable for any new
items introduced. The cost of any given item is dependent on whether the item is a manufactured item,
(finished good or WIP) or a purchased component. This distinction is set in the item maintenance
menu with the "Class" field for every item. Items of class 'M' usually have processes and routing
instructions along with Bill of Material. The cost of an item of class 'M' therefore is a product of the
cost of it's BOM and it's processes rolled up in the final item as well as the processes (operations) to
manufacture the final item. In the following sections, the process to create the cost of an item (both
standard and actual) will be discussed.
Once a Work Cell and a Routing Code have been established, the next step is to add the item master
record for the costed item. See <xref linkend="itemmaint" endterm='itemmainttitle'/> for details on
how to add items to the item master. Assuming the item to be costed has bill of material, it will be
necessary to add both the Finished product item of class 'M' and one or more raw items of class 'P' to
the item master. Once these items have been entered into the item master, the bill of material for the
costed item will need to be entered into "BOM Menu" -> "BOM Maintenance". The BOM will will
dictacte how the cost is rolled up from raw components and processes into the final product that is to be
costed.
The easiest way to understand the costing module is to walk through an example of of the costing
procedures. Let's create a hypotetical scenario usually found in the machining job shop environment.
The following example assumes that there is a finished product (a rivet for example) called 'myRivet'
that is comprised of a single bar of material (raw material) called 'myRAW'. The myRivet final product
has but one process to machine the part (turning) in the completion of the final product. This process
(or operation) will be labeled 'OP1' and will be comprised of a Work cell where the machining occurs
and a routing code that describes the nature of the process of the machining.
First, let's create the Work Cell for the turning operation to be done on MyRivet. Go to 'Routing
Menu'|'Work Cell Maintenance' and enter 'WC1' as the Work Cell. Enter a machine code of '1' and
choose the default site. You can leave desc blank and choose the default Dept from the drop down list.
Now let's assume our labor rate (how much we pay our machinist) to be $10.00)...so enter '10.00' in the
labor rate field (do not put the dollar sign). ALso enter 1 for the run crew size and enter 0 for both
setup rate and setup crew size (We will assume there is no setup). Let's further assume that we've
calculated our burden rate (electricity, rent, etc) to be $15.00 per item we produce. Enter 15.00 into the
burden rate field. Then click 'Add' to create the WC1 work cell.
Second, go to 'Routing Menu'|'Routing Maintenance' and enter 'RC1' in the Routing ID field and
enter '1' in the operation field. This will be our routing code (RC1) that describes our one operation
(turning) which we have labeled operation '1'. Enter the previously created work cell 'WC1' into the
Work Cell field along with machine '1' in the machine field. For simplicity, we will assume no setup by
entering setup hours as '0'. Now, the "Run Pieces/Hr" field should be entered as the average number of
items we can 'turn' within one hour. Let's assume we can 'turn' 30 items per hour by entering '30' in the
run pieces field. You will notice the 'run hours' field is automatically populated with the inverse of the
30 pieces per hour...or (1 / 30) to provide the hours per part. (This field is non-editable and is governed
by the "Run Pieces/Hr" field.) Once the above info is provided, click 'Add' to enter the new routing
code 'RC1'.
Third, let's now enter our two items (my-rivet and my-rawbar) to the item master. You can use the
default fields in the creation of the item master for both items. However, you will need to distinguish
the 'class' field for both. For my-rivet, choose class 'M'. For my-rawbar choose class 'P'. Let's enter
the final product first. Enter my-rivet in the part number field and choose 'M' for it's class code. In
addition, enter the newly created routing code in the routing field as 'RC1'. That is all you need to enter
for my-rivet. Click 'Add' to add this part. Now, enter 'my-rawbar' in the part number field for the raw
component and choose 'P' for the class code. Also, Enter 20.00 in the 'Material Cost' field. (We will
assume our material cost per one bar is $20.00). Then click 'Add' to add this raw component.
Lastly, let's create the bill of material association between the my-rivet parent and the my-rawbar
child. Go to 'BOM Menu'|'BOM Maintenance' and enter my-rivet for the Parent Item and choose my-
rawbar as the component. Tab down to 'Qty Per' and enter '.05'. (We are effectively saying that we can
get 20 pieces of my-rivet per one bar of my-rawbar...i.e. 1 / 20 = .05). Now, enter '1' in the operation
field...(this is the operation within RC1 that we previously defined). Then click 'Add' to create this
BOM record between my-rivet and my-rawbar.
You have now effectively created an actual cost of my-rivet (not a standard cost yet). You can view
the actual cost in the item master for my-rivet by going to the Item Maintenance screen and entering
my-rivet. my-rivet will see the info you entered previously. In the 'Cost' Panel, there are two sets of
costs...standard and Current. Click the 'Current' button to see the final cost of the item you just created.
To create a standard cost, go to menu Cost Maintenance under the Item Menu and enter the parent
part my-rivet. You can commit a standard cost of the current cost for this item by clicking 'roll' in cost
maintenance. You will then be able to review both current and standard cost and a break down of the
cost sets (material, labor, burden, overhead, outside) for the item in question including operational cost
at each operation.

Figure 7.11.1
7.12 Production Entry (Generic) (navcode: prod)

Production can entered in one of two ways. It can be recorded via the Production Entry menu or the
Production Entry By Plan menu. A description of the generic production entry method is provided
here. The production entry menu allows you to record production of your WIP or FG items at each of
the operations of that item. This menu does not validate how many times you post production for a
given item and given operation (you will want to use Production Entry By Plan if that is an issue).
This menu does however validate that the item you enter is a legitimate item and that the item has a
legitimate routing with at least one operation. Under most circumstances, reporting production of a
finished good or wip at each operation is performed within the Work Cell of that operation. It is
therefore possible to lock the allowed operation of reporting to just the operation that is performed at
it's associated Work Cell. This will prevent unintended posting of a quantity at the wrong operation.
Note: reporting of operations other than the last operation is optional. However, you must report
production quantities of the last operation. If the previous operations are not marked as milestones,
then the act of posting the last operation will auto-backflush the previous (non-milestone) operations at
the quantity posted for the last operation. This functionality is provided for situations where it is
inconvenient and unnecessary to post at each operation.
To enter production for a WIP or FG item, go to Inventory → Production Menu → Production
Entry. The userid, site, and effective date are pre-defined in the text fields. Enter the item to be
posted, and tab to the operation drop down selection box. If the item entered is unknown or the item
does not have at least one operation, an alert will be generated. Choose the appropriate operation that
is being posted. Then enter the quantity to be posted. The serialno and reference fields are optional.
Once all required fields have been entered, click 'Submit' to commit the production to the database. An
alert will be generated indicating a successful entry, and the cursor will return to the item field for the
next entry. Figure 7.11.1 shows a screen shot of the Production Entry Menu.
Figure 7.12.1
7.13 Production Entry By Plan (navcode: prodp)
Production can entered in one of two ways. It can be recorded via the Production Entry menu or the
Production Entry By Plan menu. A description of the production entry by plan method is provided
here. The production entry by plan menu is the preferred method of posting production of your WIP
and/or FG items because it allows you to better control the data entry by providing scanable job tickets
with specific quantities. These 'planned' job tickets are typically generated by the scheduling menu
where quantities and production dates are scheduled through a master schedule. However, you can
generate plan tickets from the miscellaneous plan menu.
When a plan ticket is printed (See Scheduling Menu), a bar code is provided on the ticket that
contains the value of the plan number. See Figure 7.12.2 for a sample ticket. Each ticket has a unique
plan number. Typically, each operation is provided a copy of the plan ticket. This ticket will inform
them of the part, quantity, date required, and other info necessary for the production of the specified
item on the ticket at that operation. Once production at that operation is complete, the operator will
scan the bar code on the ticket, choose their appropriate operation, enter the quantity that they
produced, and click commit. Constraints are provided at the scanning event that prevent an operator
from reporting more production than is reported on the ticket. You can scan post 'multiple' times, as
long as the quantity at each reporting does not exceed the quantity on the ticket. Also, once the posted
quantity reaches the ticket quantity for a specified operation, no further posting will be allowed for that
operation. If the last operation post quantity reaches the ticket quantity, the ticket will close and the
scheduler will see the ticket as closed in the scheduling reports.

Figure 7.13.1
Figure 7.13.2 Plan Ticket for Work Order
7.14 Inventory Adjustments (NavCode: inva)

Manual adjustments to inventory can be accomplished with the Inventory Adjustment menu found
under Inventory | Inventory Adjustments Menu | Inventory Adjustment. This menu can also be
reached by entering 'inva' in the navigation text-box on the main menu bar. There are two types of
adjustments that can be performed in this menu. You can 'issue' items in stock which will relieve
inventory for the specified item and quantity or you can execute a 'receipt' adjustment which will put
the specified item and quantity into inventory. Both transaction types require a standard 'cost'
associated with the item, therefore the item must be in the item master and it must have a standard cost
associated with it. Note: these transactions are specific (and unique) to the warehouse, location, and
serial number if you so choose to enter specific values for these. If you choose to leave these fields
blank, the inventory movement will be dependent of item and site only. You can also choose the
specific GL account and cost center to apply the issue or receipt of goods. Serial, reference, and
remarks text box fields are optional.

Figure 7.14.1
8 Scheduling

8.1 Scheduler (NavCode: schm)

Scheduling of production and/or work-in-process (wip) items is provided for by the Schedule
Maintenance menu found under the Inventory menu | Schedule Menu | Scheduler. This menu can also
be reached by entering the value 'schm' in the navigation text box on the menu bar. The schedule
maintenance menu is a master scheduling report tool that collects all planned orders generated from
various sources of demand within their 'due date' window. (See Figures 8.1.1 and 8.1.2 for images of
the scheduler). Planned orders can be considered as notifications for production of an item. Planned
orders are generated from three possible sources: 1) demand, 2) forecast, and 3) miscellaneous planned
orders. Once the planned orders are created, they can be reviewed in the scheduler based on filtering
by due date and/or Item number. The scheduler will display both scheduled and unscheduled planned
orders with the option of filtering based on this attribute as well.
Typical operation of the scheduler is to display a list of open planned orders by due date (or other
sorting options). You would then enter a schedule quantity and choose a work cell. Once these two
pieces of information have been added for each line you want to schedule, You will click the 'commit'
button. A message box will appear of how many lines you scheduled.
The option to print a schedule ticket (otherwise known as a work order ticket) is provided after
confirmation of the planned order has been executed. Once the planned order / work order is
completed, there are two options to report and close the plan order. The plan order can be manually
closed by going to Production Entry and manually entering the production of the item or going to
Production Entry By Plan and scanning the work order ticket to report the production. Both menus will
close the planned order job number once the quantity on the ticket reaches the quantity scheduled.
Figure 8.1.1 Image of Scheduler Menu:

Figure 8.1.2 Image of Scheduler Menu with right column detail:

8.2 Navigating the Scheduler (NavCode: schm)
The scheduler window consists of a main calendar, selection fields for filtering, and several tables
one of which is the main report table. See figures 8.1.1 and 8.1.2. There are also three buttons within
the filtering panel. Clicking the 'run' button loads the main report table with any planned order records
(scheduled and unscheduled) that fall within the selection window of the from / to date and checkbox
selections. The from / to date selection criteria is based on the 'due' date of the planned order. You
can also choose to show only scheduled or unscheduled planned orders by checking the appropriate
check box in the filtering panel.
Once the main report is filled with planned orders, you have the option to schedule those planned
orders by choosing a cell, choosing a scheduled quantity, and applying a scheduling date. Note: The
scheduled date is chosen from the selected date from the primary Calendar. By choosing a cell,
entering a schedule quantity, and selecting a calendar date, you can commit the planned orders to
'scheduled' by clicking the commit button. You can then click the run button to show that the planned
orders are indeed scheduled.
Clicking on a date within the calendar serves two functions. The first function is that the selected
date defines the date used for the schedule date when committing planned orders. The second function
drives the display of two tables that provide detail on any planned orders scheduled on the date selected
as well as an availability table that shows all cells that have availability on the date selected from the
calendar. The availability quantity is based on the capacity of the cell as defined in the appropriate
'cell' record in Generic Code Maintenance less the accumulated quantity scheduled on that date. These
two tables can be 'hidden' by clicking the 'hide detail' button in the filtering panel. Clicking on any
date in the calendar will re-display these two tables.
The drop-down Cell column is a collection of values that can be maintained in Generic Code
Maintenance. There are three 'default' cells that are provided with the installation. You can remove
these in Generic Code Maintenance are adjust as necessary. Within the Generic Code Maintenance
menu, the 'code' should always be 'CELL' for any new records entered. The key text field will be the
name of the cell and will be visible in the drop-down menu in the main report table. The 'value/desc'
text-box field should be defined with the capacity of that cell for a single day. An example of the three
default records are shown below in Generic Code Browse menu (navcode=genb).
8.3 Example of the Scheduler Usage

An example of a scheduling scenario is provided below. The first step is to insure that the item is in
the item master and that the appropriate toggle flags are provided. The toggle boxes highlighted in
yellow in the item master image below (figure 8.15.1) need to be checked for the item that is being
scheduled.

Fig 8.15.1

Once the item has been set up correctly in the item master, you can either enter a sales order for the
item, enter a forecast for the item, or enter a Miscellaneous Planned Order for the item. This example
considers the latter. TO enter a miscellaneous planned order, enter 'plan' in the navigational text box.
Choose the item you wish to schedule, choose the appropriate site, and enter a desired quantity. Then,
choose a date that this item is 'due' which can be interpreted as a date this item is expected to be
completed. Note: The scheduler sorts by this 'due date' so accurate date selections are imperative.
Then, click 'Add' and this planned order will be created. See image 18.5.2 for an example of entering
the planned order.
Fig 18.5.2

Once you've entered the planned order, go to the scheduler menu (navcode="schm") and choose the
due date window that is appropriate to the due date you entered in the planned order. Then click 'Run'.
You will then see the item as unscheduled in the table. Note that the 'cell' and 'qtysched' fields will be
highlighted in a green background color and the 'isSched' toggle box will be unchecked. See Figure
18.5.3 (a and b) below. Figure a is a close-up of figure b and shows the pertinent information to the
planned order.

Fig 18.5.3a

Fig 18.5.3b

Notice that the Planned Order Number is assigned automatically and is labeled as the 'JobNbr'
column in the Scheduler report table.
The next step is to enter a 'cell' and 'QtySched' for the Job number you are scheduling. The Cell is an
arbitrary value and is used to designate where the operation / work is being performed. This field is not
validated and can be any value you choose. The QtySched field is typically the same as 'QtyRequired'
which was assigned from the original quantity entered in the miscellaneous planned order you created.
You have the option of entering more or less than this quantity as desired. Once you have entered a
cell and a scheduled quantity, you then click 'confirm' and it will assign the scheduled toggle column
with a check mark, confirming the schedule. Once you click confirm, a dialoge will appear
confirming the number of scheduled items that were confirmed (in the case you scheduled more than
one jobnumber). The images below show the succession of events after confirming. You then click
'run' again, and you will notice the jobnbr record you scheduled shows the isSched toggle flag as
checked. You can then print a work order ticket, update the scheduled quantity or void the ticket as
appropriate. Note: You can only update the cell and scheduled quantity (as long as no production has
been reported). If you wish to change the scheduled date, you will have to void the schedule jobnbr
and reschedule the item. Once you have scheduled the line item, you can print the work order ticket as
shown in Figure 18.5.4.

Confirmation of schedules:

Clicking 'Run' again once confirmation Order has been executed.

Figure 18.5.4 ...showing Work Order / Job Number Ticket

Now that you have a scheduled work order created, you can then provide the ticket to your
production crew and have them complete the work order. Once the production is complete, you need
to report production to the system. The easiest method to accomplish this is to scan the Work Order
ticket upon completion of the job. Enter navigation code "planp" in the navigation text box and you
will be directed to the "Production Entry By Plan Ticket" Menu. (See image below). Once at this
menu, scan the barcode on the ticket, and it will retrieve the appropriate planned order record. Note: if
the item on the work order does not have any operations defined, a message indicating so will flash in
yellow. This is a passive warning and indicates that no raw material or labor will be committed. For
most production reporting, you will want to insure that your items have operations associated with the
manufacturing of the item, however, the system will allow you to report production without it. Enter
the quantity produced and click 'commit'. If the quantity is greater than or equal to the scheduled
quantity, the schedule will be marked as 'closed' and you are finished. If the quantity reported is less
than the scheduled quantity, then the work order will remain open until the scheduled quantity is
reached. You can override this by voiding the ticket if you no longer wish to reach the targed
scheduled quantity and you wish to close the ticket. The final image below shows the scheduler menu
of the work that was just closed. Note the text color is 'blue' and the status of the work order is
'closed'. These records will continue to show in the window because of the due date selection,
however you can hide the closed work orders by clicking the 'openOnly' toggle box before clicking
'Run' in the scheduler menu.

Scanning the Work Order ticket.

Scheduler Menu after closing the scheduled order by posting production.

Once the work order is closed and production is reported, the item master for the item just reported
will denote the quantities just reported and the transactions that occurred to update the quantities in
inventory. You will also note that the QtyOnHand field in the item master has been updated with the
addition of the quantities produced. See Image below of the Item master after scanning the work order
ticket and closing the ticket.
Image of Item Master after closing of work order ticket and production reporting:
8.4 Miscellaneous Plan Maintenance (navcode: plan)
Miscellaneous Plan Maintenance is used to create demand for production and scheduling. The
menu is under the parent Inventory | Schedule Menu | Misc Plan Maintenance. You can also navigate
to this menu by entering 'plan' in the Navigation text box on the main menu bar. Plan Maintenance is
designed to allow for quick entry of 'demand' that would have otherwise come from Sales Orders or
Forecast entries. In lieu of the latter demand, you can enter demand for any item that is defined in the
item master. The below figure shows an example of the Plan Maintenance entry screen. The process
is to choose an item and entering a quantity. Then choose a due date that you wish this item to be
completed (due) and click 'Add'. This will create a Misc Plan record that will create 'miscellaneous'
demand in the system and also be visible at the scheduling menu for scheduling / work order printing
options. The remarks field is optional and will be visible on the Work Order Ticket if one is printed.

The choice of item is a drop-down list that is assigned from items in the item master. The
assignment of the drop-down list is independent of item 'type' , but does depend on certain toggle flags
in the item master. In order for an item to appear in the drop-down list on plan maintenance, the
'scheduled?' toggle box and the 'Plan Orders' toggle box must be checked in the item master as shown
below.
8.5 Forecast Maintenance(navcode: fore)

The Forecast Maintenance menu provides a method for maintaining expected weekly production
values per item per year. Forecast schedules are best used in environments where the order to ship
cycle is relatively short and you are able to extrapolate the expected ship volume of your items from
historical information. These forecasted volumes can be translated into plan tickets by the forecast to
plan menu, thus allowing you to create plan tickets based on these expected volumes.
To enter a forecast record, enter the item, site, and year in the forecast maintenance menu and then
enter each of quantity fields representing the 52 weeks of the specified year. Once the quantity fields
have been entered, click 'Add' to commit the item forecast record. See Figure 5.11 for a screen shot of
the forecast maintenance menu.
Once you have entered your forecast records, and you wish to create plan tickets for these records,
go to Inventory → Schedule Menu → Forecast to Plan Sync. In this menu, you can select a range of
sites and items to create plan tickets from forecast records. Choose your range, and click commit. You
should then go to Inventory → Schedule Menu → Scheduler to see your newly created plan records in
the scheduler.
The Forecast To Plan Sync will only process forecast records that have a date that is greater than the
day of execution. It will not create plan records for previous weeks earlier than the day of execution.
Also, only forecast records 13 weeks out from the day of execution will create plan records. If you run
it multiple times within a 13 week period, only forecast records that have a quantity change or newly
added quantities will create/adjust plan records. All plan records previously created from forecast
records that do not exhibit a forecast quantity change for that specific due date will not be adjusted.
You can review your forecast records per item by going to Inventory → Schedule Menu → Forecast
Browse or Forecast View 13 Weeks. The Forecast Browse will simply display all items including a
select button to toggle between browse and the Forecast Maintenance Screen. The Forecast View /13
weeks will allow you to see all item forecast records, but also any plan record generated for that item
regardless of type. There are three types of plan records. Miscellaneous (MISC), Forecast (FCST),
and Order (ORD). This latter menu will allow you to see all plan records generated for this item along
with type and status of each plan record as well as the forecasted quantities for this item up to 13
weeks.
Figure 5.11a Forecast Maintenance Menu

Figure 5.11b Forecast to Plan Sync

8.6 MRP Maintenance (navcode: mrpx)
BlueSeer provides Material Resource Planning (MRP) functionality at both the finished good and
component levels based on demand. Demand is defined as any finished good item that is assigned to
an open sales order. In order for an item to be considered for MRP, the item in the item master record
must have the 'mrp' toggle flag checked. See image below of an example finished good item that has
the appropriate toggle flag checked.

The process for applying the MRP processor is fairly simple. Any open sales orders that have
finished good items with the MRP flag checked will be seen as demand by the MRP engine and that
specific items projected demand versus production will be calculated for a series of weeks and
viewable in the MRP report tool. Furthermore, any components of the finished good item on the order
will also be considered with subsequent calculations of it's projected usage versus on-hand quantity. In
order for components to be considered, these items must also have their 'mrp' toggle flag checked in the
item master. One of the initial configurations required for applying MRP processing to components is
to ensure that they are well defined in the Bill of Material of it's parent Finished Good. The MRP
processor will walk through the bill of materials for any finished good item on an open sales order and
calculate projected quantities based on the product of qty-per of the component in the bill of material
and parent item quantity on the order.
The first step to using the MRP engine is to perform the level assignment of all components in all
bill of materials. Once this step is performed, you do not have to process it again unless you change
any bill of material or you add new finished goods with new bill of materials. To process the level
assignment, go to the MRP Regenerate menu under Inventory | MRP Menu | MRP Regenerate.
This menu can also be reached by entering 'mrpx' in the navigational text box on the main menu bar.
An image of the MRP regenerate menu is provided below.

To calculate the level assignment, simply choose the site in the drop-down selection box and click
'level'. Note: this function will assign all components a maximum 'level' based on their relationship to
parents in their respective bill of materials. This is used by the MRP engine to calculate each
components usage quantity regardless of what level the component exists in the bill of material.
NOTE: The mrp engine can only walk a bill of material that is no more than 7 levels deep. The
image below shows execution of a single item with no bill of material...hence the function only reached
level 0. Any finished item with 'children' will reach level 1. 'grand-children' will reach level 2...so on
and so forth. The processing time of the level function will be commensurate with the number of
items in your item master that are 'mrp' checked and the depth of your bill of material.
Once the level assignment has been performed (once if no bom changes), you can run the MRP
processor as often as necessary. It is typically ran once a day and should be ran 'consistently' at the
same time of day to ensure repeatable results. Simply click 'MRP' in the MRP Regenerate menu
(Navcode: mrpx) and the mrp processor will process 'new' mrp records which will reflect a current
snapshot of demand versus quantity on hand versus production for finished goods and components.
See figure 8.16.2 for a typical run example of the MRP engine.
Figure 8.16.1
Figure 8.16.2
8.7 MRP Browse (navcode: mrpb)
To review the results of running the MRP processor, go to Inventory | MRP Menu | MRP Browse or
enter 'mrpb' in the navigation text-box on the main menu. The MRP Browse menu allow you to view
the results after MRP processor has run. You can filter the report by item type (class code 'M' or 'P' or
'A') as well as filtering based on item part number. Choosing class code 'M' will provide mrp details
on the finished good item while class code 'P' will provide requirement quantities on the raw
components (purchased items) in a traditional BOM structure. Class code 'A' will reflect material
requirements of item quantities that are both bought and sold in a traditional retail business scenario.
The MRP processor provides visibility of demand versus production for up to thirteen weeks. The
browse window allows you to choose the individual week. You must click the search button after
every change in week selection to display that specific weeks movement. The MRP Browse window
shows three rows of quantities for each week per item. The calculated quantities for each item are the
'demand', 'plan', and 'QOH' (quantity on hand). For each day of the week that is displayed, a rolling
reduction of QOH is display as any demand consumes the item and a rolling addition is shown as any
planned work orders compensate for the demand consumption. An example of the MRP Browse
window is shown below in figure 8.16.3. One of the better features of the MRP browse is the ability to
see the planned work orders that are used to calculate the usage as well as the specific sales orders that
comprise the demand. Another feature is the display of the recent inventory transactions for the item in
view. This extra visibility (see image 8.16.4) provides a one stop report for determining source and
sinks of item demand/usage without having to leave the report window.
With regards to monitoring class 'A' items, the mrp browse report can show the demand versus
replenishment quantities. Class 'A' items are used on both purchase orders and sales orders in typical
retail fashion, and the detailed sales orders and purchase orders that constitute the quantity movement
can be viewed in the report by clicking on the appropriate row select icon.
Figure 8.16.3

Figure 8.16.4
8.8 Retail Replenishment (navcode: reor)
The retail replenishment report specifically addresses inventory movement of items typically found
in the retail sector where items are purchased as a complete product and sold at a higher price without
modifications to the item. The same item in the item master can be used on both purchase orders
(replenishment) and sales orders (demand) in an order fulfillment scenario. Items to be used as 'retail
items' must be marked as Class Code 'A' in the item master in order to trigger specific logic within the
MRP processor, MRP browse, and retail replenishment reporting.
The retail replenishment report can be used in conjunction with the MRP Browse report to view
movement of retail items. Both reports complement each other with the replenishment report providing
signal flags for reordering merchandise and the MRP browse report showing the actual movement if
quantities as a function of demand and replenishment over a 13 week period.
To view the retail replenishment report, go to Inventory | MRP Menu | Retail Replenishment Report
or enter 'reor' in the navigation text-box on the main menu. The report provides information on items
marked as class code 'A' only. You can filter the items based on item part number in the from and to
drop down selection boxes. The report gives various information that is helpful for determining
sufficient quantity on hand to support the demand for the specific item. To run the report, simply
choose your item range and site and click run. If you click the basket button in the table for a specific
item, you will see two more panels with sales order detail and purchase order detail for this specific
item for this specific date range window (based on leadtime). To hide the detail panels, click 'Hide
Detail'. Also, there is a csv button that will export the contents of the summary panel to a .csv file.
Note: you have to click 'run' first before you can click the csv button. The PDF button is not yet
supported and is for future use only.
The following fields are provided :
• Select clicking the basket icon provides the current sales orders (demand) and purchase orders
(replenishment) for the specific item. Note: the date range of the sales orders and purchase
orders reported here are determined by the leadtime of the Item. Any open sales orders or
purchase orders with due dates up to today + leadtime will be shown. You can override the
leadtime look ahead value by checking the override checkbox and keying in a non-zero number
of days forward (ex: 90, 180, etc). You must click the run button again for any changes to the
filtered input. Note: due date is defined as the actual ship date of the item on the sales order or
expected receive date item on the purchase order.
• LeadTime this column represents the leadtime as defined in the item master menu for this
specific item. The leadtime is an integer field representing number of days. This value is used
only for the application of purchasing. It is the minimum number of days required for your
vendor to deliver the product from the date/time the purchase order is placed. Note: this field
does not actively adjust or calculate purchase order due dates. Due dates are manually
determined by the person entering the purchase order based on information about each item's
leadtime value.
• QOH (quantity on hand) this is the current quantity on hand from the viewpoint of actual
inventory in house regardless of allocated or unallocated. It can be viewed as inventory that has
not been shipped or received.
• UQOH (unallocated quantity on hand) this is simply the difference between actual Quantity on
Hand (QOH) and allocated quantity on hand (AQOH). This is the actual field that is used in
the calculation of the 'state' (status) of the item inventory.
• SafetyStock this column represents the safety stock field in the item master for this specific
item. The value of safety stock is determined manually and is based on movement I/O of the
item in question. Typically, the safety stock is set to the total quantity sold within the timespan
of the leadtime. For example, if item X has a lead time of 42 days and the average quantity
sold with 42 days is 100 units, then the safety stock should be set to 100. However, this is
completely subjective to the product and the nature of the retail business and should be
reviewed and set with realistic variables.
• POQty (purchase order quantity) this column represents a summation of any open purchase
orders for this specific item's quantities. The purchase orders selected are the ones with due
dates for the expected delivery of the item within the leadtime window of the item forward from
the current date. For example, any PO with an expected delivery date of the item that is greater
than today but less than today + leadtime is considered. The resultant summed quantity will be
considered as legitimate supply for the calculation of item supply versus demand.
• DemandUnallocated (sales order quantity) this column represents a summation of any open
sales order with this specific item that does not have enough UQOH to meet the order quantity.
The sales orders selected are the ones with due dates for the expected shipment of the item
within the leadtime window of the item forward from the current date. For example, any Sales
Order with an expected ship date of the item that is greater than today but less than today +
leadtime is considered demand. Furthermore, any quantity that could not be allocated because
of insufficient UQOH will be summed here.
• FwdQty (sales order quantity forward) this column is only a representation of all sales order
quantities for this item for the date range of current date through leadtime. This is all open
quantities independent of allocated or unallocated. This field is used in the Ratio calculation
along with FcstQty. This field is not used in assignment of status.
• FcstQty (forecast qty) this column represents the total summed quantities of all forecast
records for this item for the date range of current date through leadtime. This field is used in
the Ratio calculation along with FwdQty. This field is not used in assignment of status.
• Ratio this column is used to gauge the legitimacy of the forecast of this item. This ratio
should reflect a low percentage if both forecasting is accurate and the demand is dispersed
throughout the duration of the leadtime. For example, if the leadtime of the item is 40 days
then FcstQty is the sum of forecasted quantities in the next 40 days. Likewise, the FwdQty is
the sum of the open sales order quantity for this item for the next 40 days. The ratio of FwdQty
to FcstQty should reflect (1 / leadtime) reduction (assuming even disbursement). Given a 40
day leadtime, it is expected that FwdQty should be ~ 2% of forecasted quantity. The
legitimacy of the ratios are subject to order frequency and size, but can be used to gauge how
fast the consumption of forecast is occurring. Large ratios should be considered a red flag.
This column is not used in the assignment of the status field, and should only be used as a
potentially useful indicator.
• Status The status field is a calculation that indicates one of four possible color-coded values
based on the logic below :
→ urgent Any item where the unallocated quantity on hand (UQOH) plus the expected PO
delivery quantities is less than the total unallocated demand for the given date range (today
+ leadtime). In this scenario, there is neither sufficient on-hand quantity nor PO
replenishment quantity to meet existing and new demand.
 → Safe / Warning Any item where the unallocated quantity on hand (UQOH) is less than the
current unallocated demand, BUT expected purchase order replenishment is sufficient to
cover the current unallocated demand in a just-in-time scenario. The warning aspect exists
as a reminder that the UQOH is less than safety stock, and this item should be reviewed for
replenishment.
→ Warning This is the safety stock flag. This is an indication that UQOH has fallen below
safety stock but UQOH is sufficient to meet current demand. In this case, unallocated
demand should be zero since UQOH is sufficient to meet demand but still below safety
stock. This item should either be reviewed for replenishment or reviewed for legitimate
safety stock value.
→ good Any item where the unallocated quantity on hand plus the expected PO delivery
quantities is greater than the total demand for the given date range (today + leadtime) and
greater than the safety stock. UQOH + POQty > DemandUnallocated AND UQOH +
POQTY > SafetyStock. This status indicates that all is well and that both demand and
safety stock values are accommodated.

The status column values are based on the variables within the leadtime window which is unique for
each item. You can override this by checking the Override checkbox and keying in a number of days to
look forward. This new timeline window will be defined as starting today to (today + DaysForward).
This new date range window will be applicable for all items regardless of their specific leadtime. You
can use this to take a larger look at forward demand and purchasing timeline windows....assuming you
have demand and replenishment orders scheduled at more distant dates. A good rule of thumb is to
look at days forward > than 2 x your largest leadtime. If safety stock and replenishment orders are
satisfactory, then you should see mostly good statuses.
Figure 8.18.1 shows a sample screenshot of items that have status reflective of all four possible
outcomes.
Figure 8.18.2 shows a sample screenshot of items with both the sales order detail and purchase order
detail screens visible for each item. Note: the order of panels is 1) summary panel, 2) sales order
panel, 3) purchase order panel. To hide the detail panel, click 'Hide Detail'.

Figure 8.18.1

Figure 8.18.2
9 Freight Management

BlueSeer offers freight management functionality from both the freight carrier perspective as well as
the customer perspective. The unique perspective (and accompanying functionality) is governed by a
configuration setting in the Freight control file. This should be set for one or the other perspective
applications at implementation/installation time.
The freight carrier application perspective allows a freight/carrier company to manage their freight
orders, whether manually entered or received as EDI 204 transactions from their customer. The freight
carrier also has the ability to manage drivers and vehicles as well as schedule these resources based on
requirement dates of the individual freight orders.
If the customer perspective is chosen, the application provides a manufacturing company the ability
to manage and schedule freight orders of their shipments that require a freight carrier to deliver. In this
perspective, the freight order management module can be used to communicate the desired freight
requirements with multiple prospective carriers using EDI 204/990 order/response exchange
communication.
A major difference in the two configuration options is the financial entries resulting from
committing/closing the freight order. In the freight carrier application perspective, the closing of the
freight order generates an invoice and creates accounts receivable entries for future payment from the
customer to be applied once the delivery has been made. In the customer (manufacturer) application
perspective, the closing of the freight order creates Accounts Payable entries that facilitate issuing
payment to a carrier for their services upon the carrier submitting an invoice to the customer
(manufacturer).

9.1 Freight Control (navcode: cfoc)

The Freight control menu controls some of the pre-production configuration options that govern
how the Freight Maintenance menu operates. It can be accessed by entering 'cfoc' in the navigation
text-box on the main menu bar. The default configuration with the initial installation sets the
application as "Freight Carrier" with the toggle-box checked. This defines the application to operate
from the Freight Carrier perspective and therefore all Freight Orders that are generated on behalf of the
carrier, to invoice to their customer regardless of whether the freight order was created manually or via
EDI 204 from the customer. If you are a freight carrier, you will want this toggle-box to remained
checked. However, if you are a manufacturer or business who will be creating the freight order to
schedule / assign a freight carrier, then you will want to uncheck the toggle-box and click the update
button. This configuration choice should be made immediately after installation and should not be
changed after production use. The application is mutually exclusive between freight carrier
perspective and customer (manufacturer) perspective.

If the freight carrier application is checked, you can also define the automation of the EDI 990
response if you are a freight carrier communicating with your customer via EDI 204/990 transaction
sets. If the "Send 990" toggle-box is checked, the system will automatically send a 990 response to the
customer upon assigning the status of the freight order to 'scheduled'. You will also be prompted upon
setting the status to "scheduled" in the freight order maintenance menu as to whether or not you want to
send/resend the 990 as well. Figure 9.1.1 shows the freight control menu screen.
Figure 9.1.1

9.2 Freight Order Maintenance (Carrier perspective) (navcode: cfom)

The Freight Order Maintenance menu is the primary menu governing the creation and updating of
freight orders. It can be accessed by entering 'cfom' in the navigation text-box on the main menu bar.
A screenshot of the freight order maintenance menu can be seen in figure 9.2.1. There are two ways to
create a freight order. You can manually create a freight order and provide all the necessary details by
clicking the new button and entering the information manually. The second method is using EDI. If
you are receiving 204 EDI transactions from your customer, the freight order will automatically be
created/updated by the transaction. This requires EDI configuration for your customer trading/partner
in the EDI menu of the application. Once these configurations are established, the orders will generate
freight orders automatically upon receipt of a 204 EDI transaction. The manual approach is required if
you are not using EDI however. To create a freight order manually, click the new button and choose
your customer from the customer code drop-down list. You can also enter a 'customer order' number
as well if the customer has forwarded their unique number for the freight order. The revision and
default field settings can be left as-is. The default toggle-box is used only when there is more than one
revision of this freight order. Both the service type and equipment type drop-down fields are filled
with values that are assigned in Generalized Codes. Choose these fields as necessary based on your
requirements. The truck id, driver, and broker drop-down fields have values that are pulled from their
respective maintenance menus. These will need to be created prior to creating the freight order to use
them. You can leave truck id, driver, and broker fields blank if necessary. The status field will always
be set as 'pending' on initial creation of the freight order (both manual and EDI based). Once you have
the freight order created and confirmed all scheduling, you will want to set the status to 'scheduled'.
Once the order has been fullfilled, you can set the order to 'delivered'. The 'decline' option is used if
the order is EDI based, and you decline the 204 EDI transaction. This action will close the freight
order. The 'cancelled' option is used if the customer or you decide to terminate the freight order. The
'closed' option is automatically assigned upon clicking the 'confirm' button. Confirming a freight order
will close the order and create an accounts receivable transaction which will in turn create an invoice
for you to send to your customer, effectively closing the transaction. Click the 'confirm' button only
when you are sure the freight has been delivered and the transaction is complete.
The rate field governs the costing of the freight order. There are two types of rates: flat rate and
mileage rate. The flat rate option uses only the dollar amount in the rate field to determine the overall
cost of the freight. If the mileage rate option is chosen, the value of the rate field multiplied by the
value of the mileage field is used to determine the overall cost. Toggling between these two rate
options will automatically adjust the total cost field based on these two schemes. Both the rate field
and mileage field are 'header' level fields, independent of the individual stops. You can assign the cost
based on the individual stop (rate and mileage) values by clicking the 'derived' toggle box. The values
in the header rate and mileage fields will be overwritten with the sum of the detailed 'stop' rate and
mileage values. This is true for the weight field as well. Checking the toggle-box next to the weight
field will override the header weight assigned with the sum of the individual stop weights.
The total cost of the freight order is the sum of the rates (whether flat or mileage) plus any charges
as assigned in the Charges panel. You can create individual charges in the Charge panel for a variety
of scenarios that add additional cost to the freight order. Examples include a flat rate for shuttle tarp
and tie, fuel surcharge, etc. The "Description" field in the Charge tab will be visible on the final
invoice print along with it's corresponding value. You have the option of choosing a fixed charge by
choosing 'amount' in the amount type field, or a percentage based charge by choosing 'percent' in the
amount type field. You can even provide a discount in the summary panel by choosing 'discount' in the
summary type.
To add stops to the detail of the freight order, click on the location panel in the menu. Click the
'new stop' button. This will highlight the fields for addressing and scheduling and assign the first stop
with a numeric number which will appear in the stop sequence drop down list. You must click the 'add
stop' button to assign it permanently into the stop sequence drop down list. After entering the address
and scheduling information, click the 'add stop' button to add this stop to the freight order. Note: once
you have added all your stops, you must click the 'add' button on the main tab to fully commit the
freight order and stops. The first stop assigned initially defaults to stop type 'load'. The second stop
created initially defaults to stop type 'unload'. You can change these as necessary. Once you have
created a stop...by clicking the 'stop add' button, you can revisit that stop info by choosing the stop in
the stop sequence drop-down list. The order/item information is optional and can be left blank for
creating a stop detail record. Once your stops have been added, go back to the main panel and confirm
the overall cost is as expected, then click the 'add' button. This will commit the freight order to the
database. You can then update as necessary. Once you are sure the scheduling and driver information
are correctly assigned, you can set the status to 'scheduled', which will remove it from the pending list
in the freight order browse/report menus. The freight order at this stage is ready for delivery. You can
also print a copy of the freight order to PDF or printer using the print field. Once the delivery has been
completed by the driver and you are prepared to invoice, click the 'commit' button at the bottom left.
This will establish an accounts receivable record per the terms of the customer and create an invoice to
be sent to your customer. You can view/print the invoice in the invoice browse menu (navcode: invb).
Figure 9.2.1

9.3 Freight Order Browse (navcode: cfob)

The Freight Order Browse menu allows you to review your freight orders and distinguish orders
based on customer code and/or status. It can be accessed by entering 'cfob' in the navigation text-box
on the main menu bar. The browse menu is a convenient method for viewing and reporting freight
orders. It is typically used for separating freight orders that have not been scheduled from those that
are pending. There is a status drop-down field that can be used to choose the specific status of records
you are seeking, or you can choose the blank option in the drop-down which will retrieve all records
matching the other field options selected. A screenshot of the freight order browse record is provided
below in figure 9.3.1.
Figure 9.3.1

9.4 Freight Order / Driver Scheduler (navcode: cfow)

The order / driver scheduling menu provides a convenient method to schedule / review your freight
orders in addition to driver availability. It can be accessed by entering 'cfow' in the navigation text-box
on the main menu bar. Once a freight order has a driver dedicated to the order and it's status set to
'scheduled', the driver assigned will be committed to that pickup / delivery date window and cannot be
assigned further for that date window. You can view all freight orders and driver availability within
this menu. The driver information in the right panel will always be visible regardless of any orders
being shown in the left panel. The current date window of visibility is one week out. Any drivers that
are assigned to freight orders will have their specific delivery window shown in blue as 'scheduled'.
Otherwise, it will be shown as open availability. You can click on the flag in the first column of the
freight order table to go directly to the freight order maintenance menu for that specific order and
adjust the order as necessary. A screenshot of the order / driver scheduler window is shown in figure
9.4.1.
Figure 9.4.1
10 Finance

10.1 Chart of Accounts Maintenance (navcode: accm)

BlueSeer provides a sample chart of accounts for convenience. However, you will probably want to
add your own or edit the given accounts to suit your needs. The account master maintenance menu is
reasonably straight forward. There are only a few fields to consider in order to create an account
record. The account 'ID' itself is the primary key to the account master table. This field is your account
number and can be a max of 10 chars (no spaces). The account number is a unique field. You will
need to assign a 'type' value to the account. There are four account types accommodated in BlueSeer.
They are Asset (A), Liability (L), Income (I), and Expense (E). Each record must be assigned one of
these four types. The Description field is arbitrary and should be as verbose as necessary (up to 50
chars). The only other field necessary to describe the account is the currency assignment. At this time,
BlueSeer only accommodates US Currency (USD).
To add or edit an account, go to 'Finance'|'Ledger Setup'|Account Master Maintenance menu. Once
inside the account maintenance window, enter your account ID, Description, Type, and Currency. Once
the fields are entered, click 'Add' and a message box will appear indicating successful entry of the
account number. To Edit any account, click the search button beside the account id field. (Note: you
can search by account or by description of account; depending on search button clicked). Clicking on
one of the search buttons will bring up the browse panel where you can search by text or simply click
'Find It'. If you click 'Find It' without a search text, the browse panel will return all account records.
Simply click on the account number that you want to edit/review, and it will return to the account
maintenance screen with the appropriate record. Once you've edited your fields, click 'Edit' and a
message box will appear indicating the success or failure of your edit. See Figure 9.1.1 for a screen
shot of the Account Maintenance screen.

Figure 10.1.1
10.2 Ledger Calendar Maintenance (navcode: calm)
The General Ledger Calendar is maintained under the Finance main menu. Go to the Ledger Setup
Menu and then choose the Ledger Calendar Maintenance menu. The ledger calendar allows you to
assign beginning and ending dates to financial reporting periods within a given calendar year. You can
span over years if your planning calendar requires so, or you can simply use the accepted months
within a given year as your accounting periods. This example will illustrate. To assign period 1 in
calendar year 2000, choose "2000" in the year drop down box, and then choose period 1 for your first
period. Choose a beginning and ending date from the appropriate date icon box and then click the
'Add' button. You also have the option to close the accounting period by clicking the 'closed?'
checkbox. It is a generally accepted practice to close all periods except the operating period to prevent
transacations from being posted with erroneous dates. Closing the previous period and opening the
new period is generally done at the end of the period by an appropriate controller. You can use Ledger
Calendar Browse to see a list of all the periods and their assigned beginning and ending dates. To Edit
a year / period, you simply choose the year and period and click 'Get'. If the record has been
established previously, the beginning and ending dates will be populated. Edit the dates as you require,
and then click Edit. Never edit a currently effective year/period record...(operating period). It could
have undesirable consequences.

Figure 10.2.1
10.3 Currency Maintenance (navcode: curm)
The default currency in the BlueSeer application is “USD”. You can create other currency records
and set the default to the currency denomination of your choice. Once you've created and set the
system currency in the Default Maintenance menu, all transactions will be performed with that
currency unless manually chosen otherwise. To create a currency ID, enter 'curm' in the navigational
text box. This will bring you to the Currency Maintenance screen. Click the new button, and enter a 3
character currency code. These codes are not validated. The only restriction is that the code must be 3
characters in length. You will need to enter a description as well. Once the code and description have
been entered, click the add button to commit the new currency ID. See Figure 9.3.1 for the currency
maintenance screen.

Figure 10.3.1

Once you have created your new currency code, you will need to ensure that the system recognizes
this currency as the default currency. You can get to the Default Maintenance screen by navigating to
Admin parent menu—Default Maintenance, or enter 'defm' in the navigational text-box. Once you are
at the Default Maintenance menu, enter your new currency ID in the default currency field and click
'update'.
Figure 10.3.2
 Now that a new currency has been defined and set as the system default, any new customer or
vendor record creation will automatically apply this default currency code as the default for that
specific customer or vendor and any subsequent orders or purchase orders. Note: previously created
customers and vendors will have to have their currency codes adjusted as necessary in the appropriate
customer and/or vendor maintenance screen.
Also, customer prices lists and vendor price lists must be adjusted for the new currency if you
already have price lists records created at the time you create the new currency. It's important to assign
your default currency early in the implementation so that any subsequent address records and/or price
list records will have the correct currency.
10.4 Exchange Rate Maintenance (navcode: excm)
The exchange rate maintenance menu is used to assign currency exchange rates against the default
system currency. Typically, you would want to assign your default system currency in default
maintenance (navcode: defm) and then apply whatever alternate currencies that are applicable to your
system. The rate value assigned in the menu is defined relative to one unit of default currency. For
example, if your default currency is USD and you determine that you will be selling product in
Canadian currency, then assign a rate of x.xxx CDNs to one unit USD. The drop down selection box
in the menu provides alternate currencies that have been defined in currency maintenance (navcode =
curm).
All general ledger financial reports are reported relative to the base default currency. For each
ledger transaction, a base amount (defined as amount in default currency) is calculated and assigned to
specific “base_amt” fields in the gl_tran and gl_hist tables. If the currency applied to the order is the
same as the default currency, then the glh_base_amt and glh_amt fields are the same. However, if an
order is placed in a currency that is different than the default system currency, then glh_base_amt will
be assigned an amount relative to the base currency and the glh_amt field will be assigned a value
relative to the order's specific currency that was applied. The calculation of base_amt uses the
exchange rate at the time of the transaction.
The exchange rate menu can be accessed by using navcode: excm or clicking on the exchange rate
maintenance menu under Financials | Ledger Setup. The base code value will be disabled from user
input and is assigned by the default maintenance menu. Any exchange rates previously applied will be
visible in the table provided. You can click on the specific record in the table to 'update' the rate. If it
is a new record, then choose your alternate currency, enter an exchange rate, and click add.

Figure 10.4.1
10.5 Department / Cost Center Maintenance (navcode: depm)
BlueSeer considers the Cost Center and Department to be the same in definition and is used
interchangeably within the application. The Cost Center (department) is defined as an operational
entity within a business that incurs a cost whether that cost be labor, burden or a combination of both.
One of the first steps in the implementation process of BlueSeer is to define one or more cost
centers. The code used as the identity key for the department record can be up to 8 chars long (no
spaces). When setting up a new department/cc, you will be asked to assign GL accounts to several
fields associated with capturing labor, burden, and cost of operation costs. To add a new dept/cc, enter
a code (up to 8 digits) for the dept/cc id and then occupy the account fields with the appropriate GL
account. The accounts are validated, so these accounts must exist in the chart of accounts before
continuing. Once the fields are completed, click 'Add' to enter a new dept/cc record. You can browse a
list of the dept/cc records under the menu "Finance"|"Ledger Setup"|"Dept/CC Browse". The Browse
will allow you to select any dept/cc for further info and editing.

Figure 10.5.1
10.6 Bank Maintenance (navcode: bank)
Bank Maintenance allows the addition or updating of information related to banks and associated
account information. These bank records are used a selection drop down boxes in several modules
including the customer master and vendor master. Bank codes associated with various customers
and/or vendors are used during shipping and receiving transactions as they pertain to GL account
credits and debits. The bank record itself is simply an association of a GL account with a specific bank
code. It can be used if you have more than one bank for specific customer payments or accounts
payable check runs for vendors. At least one bank record must exist. A default bank record is provided
with BlueSeer. You can delete, update, or add your own as necessary.
To add a bank record, go to 'Finance'|'Ledger Setup'|'Bank Maintenance' menu. Enter a 2 digit code
(no spaces) for your bank code and provide a description of this bank (optional). Enter a valid GL
account for this bank and choose the currency code. (Currently, only USD is allowed in this version).
Check the 'Active' checkbox and click 'Add' to save the record. Note: You can inactivate bank records
by unchecking the check box. This will prevent transactions from further using this bank code if
unchecked without having to delete the record.
To update a bank record, you can either go through the Bank browse menu to access the target bank
code or you can go directly to bank maintenance and enter the bank code then click 'get'. Once the
record is retrieved, you can edit the fields within the menu and click 'update' to save the new info
associated with this bank id.

Figure 10.6.1
10.7 Tax Maintenance (navcode='taxm')
The tax maintenance menu is used to maintain a collection of tax elements that can be applied at the
customer level or at the item level. To create or update a new tax code, enter 'taxm' in the navigational
text-box. This tax code can be referenced in the customer master to associate this applicable tax code
to all sales orders associated with the customer. The tax code can also be applied at the item level by
associating this code with an item in item maintenance. This is known as a Material Tax at the sales
order detail level and on invoice documents. Any subsequent sales orders with an item that has a tax
code associated with it will have the tax applied automatically.
To create a new tax code, click the new button and enter an arbitrary tax code that is less than or
equal to 8 characters. Then enter one or more tax elements that will be associated with this tax code.
After you've entered the tax element and percent value, click the 'AddElement' button above the
element table. You can delete an element as well and re-add to update the percentage value. Once all
elements have been added, then click the 'Add' button at the bottom of the menu.
A tax element is a fixed percent applied to the total tax. Tax elements are then summed up for all
elements in a single tax code to arrive at a total fixed tax percentage. For instance, if you have a tax
code comprised of two elements at 5 percent and 2.3 percent, then you will have a total tax code value
of 7.3 percent applied at either the sales order header level or at the item level depending on where it is
associated. Figure 9.7.1 shows the tax maintenance menu. A further example is provided below in
Figure 9.7.2.

Figure 10.7.1
 As another example of combining tax codes, a sales order was created for a customer that had a tax
code 'HST' applied to the customer master record. The value of the HST tax was 4 percent. There was
also a material tax applied to the item in the sales order. The material tax was comprised of two
elements totaling 7.3 percent. The Item price was $5.00 and quantity of 6 was invoiced. The resultant
tax values are displayed at the bottom of the invoice print. The material tax value was $2.19 and
applied at the item level before HST was applied. The HST value was $1.20 and applied to the overall
order independent of the item material tax. The overall summed tax was $3.39 and added to the $30.00
gross price to arrive at a net price of $33.39.
Figure 10.7.2
10.8 Tax (GSTIN)
The GSTIN tax specific to India tax rules can be applied with the Tax Maintenance menu. Several
other maintenance menus will have to be adjusted as well so that the GSTIN numbers for both vendor
and customer will be visible on the Invoice print as well as the added tax amount shown at the bottom
of the invoice print. A special invoice print (jasper file) is dedicated to the GSTIN functionality and
can be found in the jasper directory as the file 'inv_gstin.jasper'. The following steps can be taken to
use this specific jasper file in conjunction with applying a GST tax to each customer order and
subsequently to the invoice.

Step 1. Create the appropriate tax record in Tax Maintenance (navcode=taxm) as shown in
figure 9.8.1.
Step 2. Go to the Customer Maintenance Menu (navcode=cusm) and find the specific customer
that will require the GST tax record. Choose the newly created Tax Record in the Tax drop
down menu. Also, enter the value 'inv_gstin.jasper' in the field labeled 'Invoice Format' as
shown in figure 9.8.2.
Step 3. Go to Generic Code Maintenance (navcode=genm) and create a new record with
key1='gstin', key2=<customer code>, value=gstinnumber as shown in figure 9.8.3. Create a
record for your site code as well as shown in figure 9.8.4. Note...you will want to label your
site gstin value with 'gstin:' as shown in figure 9.8.4 so that the invoice print shows the label.
The customer label is hard-coded in the code as 'GSTIN#'.

Once the above three steps have been completed (for each customer), then any sales orders entered
for that customer will receive the GST tax amount automatically added to the sales order total. When
the sales order is committed to invoice, the invoice print will show the GST tax at the bottom of the
print as well as the appropriate GSTIN numbers for your site as well as the customer. The customer
GSTIN number will be in a dedicated box above the item detail. The site GSTIN number will be
visible below the Site Address. See figure 9.8.5 below for an example print with GSTIN info applied.
Figure 10.8.1
Figure 10.8.2
Figure 10.8.3

Figure 10.8.4
Figure 10.8.5
10.9 Trial Balance Report (navcode=trba)
BlueSeer offers a trial balance report. To review the report, enter 'trba' in the navigation text-box on
the main menu bar. The trial balance report is generic in nature and adheres to the standard definition
of the report. The report shows debits and credits for all accounts for a particular year and period. You
can choose to hide accounts with zero amounts by clicking on the appropriate checkbox. You can also
view department/cost center detail by again clicking on the appropriate checkbox. For each filter
change whether it be a change in year, period, or check-box, you must click the run button again to
show the refreshed information in the table.
You can also view the detail transactions of each account by clicking on the 'basket' icon in the first
column. This will open a second panel in the main panel with the detail transactions for the given year,
period range. To hide the detail panel, click the hide detail button at the top of the main panel.
As indicated above, the trial balance report is generic in nature and applies the following rules to
whether an entry is accumulated in the debit versus credit column :

Account Type Credit or Debit

Assets (type='A') Debit

Liabilities (type='L') Credit
Income/Revenue (type='I') Credit
Expenses (type='E') Debit
Owners Equity (type='0') Credit

The purpose of the trial balance is to ensure that the sum of all debits equals the sum of all credits
within the range of all accounts. The sign on the Credit column has been adjusted (* -1) to ensure that
the summed values (Total Debit and Total Credit) at the top of the report have the same sign. This is
for convention only.
The total credits and total debits should match. If not, then review the transactions for a potential
duplicate that has been entered via standard transaction maintenance.
An example of the trial balance report is provided in figure 9.8.1 below.
Figure 10.9.1
10.10 Income Statement Report (navcode=inst)
BlueSeer provides an income statement report that allows you to monitor the profitability of your
business. To view the report, enter 'inst' in the navigational text-box on the main menu bar. The report
is filterable by site, year, and financial period. The report is generated and viewable within a table
when you click 'run', however, you can also review the report by clicking 'print' which will open a
jasper view window. This window will allow you to save the report in PDF or print the report to a
printer of your choosing.
The default contents of the income statement are customized toward a manufacturing environment.
The categories listed on the report can be adjusted for content. The categories such as Sales, Cost of
Goods, General and Admin, etc are fixed, but you can adjust which accounts are reported in these
categories by using the Income Statement Definition menu. To view this menu, enter 'insd' in the
navigational text-box. The definition menu allows you to choose a range of accounts for your category
and/or specific accounts that are either included or excluded. For example, the default 'cogs' category
(cost of goods sold) is shown in figure 9.9.1.
Figure 10.10.1

Once you've adjusted the accounts in the categories as you desire, you can run the report via
navcode='inst'. Note: All transactions must be posted before you attempt to run the income statement
report. You can post all entries by entering 'post' in the navigational text-box and click 'get count' and
'post' respectively.
Figures 9.9.2 and 9.9.3 below show the income statement report menu as well as a sample print of the
jasperviewer generated PDF report.
Figure 10.10.2

Figure 10.10.3
10.11 Account Reconciliation (navcode=recon)
The account reconciliation report supports the comparisons of the current Ledger entries versus an
arbitrary bank statement for a specific asset account. To use the reconciliation report, enter 'recon' in
the navigation text-box on the main menu bar. Note: It is imperative that all financial transactions
have been posted before running this tool. Typically, this reconciliation process is performed at the end
of a financial period or month, and the previous period/month transaction records are reconciled with a
statement provided by your bank institution.
Figure 9.10.1 shows the main screen of the reconciliation report. The first step is to enter the ending
balanced from your bank statement for the account in question. After entering in the statement balance,
the other fields will become activated. In most situations, the GL Previous Ending Date will
automatically be assigned to the end date of the previous financial period/month. The GL Previous
Ending Date is essentially the date you ran the reconciliation report and cleared the transactions on
your previous run. This date is inclusive in that any transactions on that date have been cleared as well
(your previous run) and indicates your GL balance for this account as of that date. The GL To Date
will effectively be today, however, you may have to adjust this date depending on how well your GL
effective date of transaction matches your Bank effective date (post date).
Once you've entered the GL To Date, choose your site and bank account (typically your primary
asset cash account) and click the run button. The summary of totals can be seen in the top right portion
of the application. The Statement Balance field is simply a replication of what was entered in the
Statement Ending Balance text-box. The GL Previous Ending Balance is the total balance of your
previous financial reporting period/month for the specified account. The Selected Total value
represents all the transactions that were retrieved from the run command that have a 'check' mark in the
check-box column in the table. Any transaction that has not been cleared will be labeled as 'open' in
the status column. Note: After you click the run button, you can choose all the transactions by clicking
the 'toggle all?' checkbox. Removing the toggle check flag will remove all selections in the check-box
column as well. You will notice the 'Selected Total' change after each selection of an individual record
or the toggling on/off of the master toggle check box.
The 'Difference' label in the top right hand portion of the application is the primary indicator of a
successful reconciliation. If the difference is not 'zero', the total amount in discrepancy will be
displayed in red text. See Figure 9.10.2. If the difference is zero, the value will be displayed in blue
text. The Difference value is calculated as the difference between the Statement Balance and the sum
of the Previous Ending Balance and Selected Totals. See Figure 9.10.3. Once you are satisfied with
reconciliation and the difference is zero, you can commit the records as reconciled by clicking the
'commit' button. This will register these transactions as reconciled with your bank statement and will
be labeled as 'cleared' in the status column in the table.
You should typically run this application once a month or as required. Consistency in execution and
frequency is key to ensuring your ledger account in the application matches your bank statement. If
you see discrepancies, review the transactions that are in question. It may be that you have not entered
a transaction in BlueSeer to accommodate a deposit or expense recorded by the bank. It also may be
possible that the bank has a questionable transaction that should be reviewed for legitimacy. There may
also be situations where you have doubled a transaction by mistake. In any case, review and correct the
offending transaction before committing the set of transactions as cleared.
Figure 10.11.1
Figure 10.11.2

Figure 10.11.3
10.12 Financial Transactions Overview
In this section, you will receive a brief overview of the financial transactions that occur behind the
scenes when various functional module events occur (shipping, invoicing, etc). The majority of the
financial transactions hitting the ledger occur automatically upon the event of shipping, production,
receiving, inventory adjustments etc. These transactions are written to the gl_tran table all throughout
the production day, and the number of these transactions can be rather large depending on depth of bill
of material, number of routing steps, and other variables. The GL Posting menu is used to post the GL
transactions temporarily stored in the gl_tran table to the gl_hist table where they are committed
indefinitely. This Posting procedure is typically ran once at night or (close of business). Posting also
updates ledger account balances up to the point of posting.
There are a variety of transaction types. Most are used for manufacturing cost and inventory
tracking and are committed automatically by the 'events' of inventory adjustments or production
reporting. The only available costing method in BlueSeer is standard costing. All of the various
transactions incorporated within the production menus are designed within the scope of the standard
costing paradigm. The available transactions that are provided by BlueSeer are typical transactions
generally found in a manufacturing environment where the financial worth of goods are issued and/or
received into accounts based on operations in a workflow. The list of these types of transactions are
provided below:
NOTE: These transaction types are also used in the tran_mstr table for inventory and
miscellaneous transaction monitoring as well as Ledger transaction descriptions.

➢ RCT-PURCH (Receive Raw Material from Purchase)

➢ ISS-WIP (Issue Raw Material or SUB to Assembly)
➢ RCT-SUB (Production of SUB-Assembly)
➢ ISS-SUB (Issue of SUB to FG)
➢ RCT-WIPFG (Production of WIP (of FG) )
➢ RCT-FG (Production of FG final OP)
➢ ISS-SALES (Issue FG to Sales)
➢ ISS-MISC (Issue of Miscellaneous Material (RAW,SUB,FG) )
➢ RCT-MISC (Receipt of Miscellaneous Material (RAW,SUB,FG) )
➢ LOC-TRNF (Location Transfer of Material (RAW,SUB,FG) ) *

* NOTE: Location Transfer does not generate financial transactions. Only inventory
movement.

An example of the mechanics of the above transactions would be helpful in understanding the nature
of the above transaction codes. The example scenario provided below walks through most of the
transactions mentioned above. The scenario includes a single item and an empty (zero-valued) ledger
accounts. The items and accounts used in the scenario are already setup and present in the Demo
Version of BlueSeer. The item, item cost, Bill of Material, and Routing/Work Center are all pre-
defined, so you can walk through the scenario provided below with your own installation of the demo.

10.13 Accounts Payable Transactions (Procure to Pay)

The top-level business process of “procure to pay” has several double entry transactions that apply
against the general ledger, accounts payable tables, and transaction history tables. Most of these entries
are governed by assigned fields in the vendor master as well as various control master records.

10.14 Financial Transactions Example Scenario

We are going to be using the data provided in the Demo Installation. All the necessary components
to perform the below processes are provided in the demo instance. Below are the processes along with
screen shots of the Unposted Ledger Report immediately after the process event occurred. You can
access the Unposted Ledger Report under Finance → Ledger Reports → Unposted Transactions.
NOTE: By definition, all Credits are of (-) sign and all Debits are of (+) sign. Negatives are
surrounded by parentheses.

1. Receipt of Raw Material from a Purchase. Transaction type: RCT-PURCH

• For our first step, we are going to receive raw material for our inventory. This raw material
is used as material in the BOM of the finished good product we will be posting and selling
in subsequent transactions.
• The below receipt transaction was accomplished by creating a Purchase Order for item
“p0001” at standard cost $0.10 / each for 100 pieces, and then receiving that item into
inventory. (The event of receiving inventory into the system immediately triggers Ledger
transactions. The creation of Purchase Orders do not).
• Notice the credit of the AP Trade account and the debit of the Raw Inventory account.

2. Production posting of Finished Good Item. Transaction type:

• Now we are going to post production of a finished good item that consumes the raw
material in the BOM and consumes labor and burden from each operation that is defined to
manufacture the item.
• We will be posting production of item “10-1001” from the demo installation at standard cost
$0.25 . A screen shot of the standard cost breakdown along with the operations to
manufacture item 10-1001 is provided below.

• Once we post production under Inventory → Production Menu → Production Entry, you
will notice that there are multiple transactions occurring during the posting of a finished
good. The raw material is issued to WIP, labor and burden costs are captured at each
operation of the manufacturing steps of the finished good, and transfer of finished good
from WIP to FG at the last operation signifying a complete state. All of these transactions
occur at standard cost.
• There are two operations (Assembly (op 100) and Pack op (200) ). Each one of these
operations have labor costs and burden costs which stem from the department fixed labor
and burden rates where the operation occurred and the expected run rate (parts per hour) and
setup costs. You can view these variables in both the Routing Maintenance and Work
Center Maintenance screens respectively. The Routing ID for item 10-1001 can be viewed
in Item Maintenance menu. With the Routing ID, you can also view the work center called
in each operation of the routing.
• The below screen shot shows the labor, burden and material transfer of reporting production
of item 10-1001 at 100 pieces. You will notice that the labor absorbed account was hit at
each operation for ($.03 * 100) and ($.0188 * 100) respectively (op 100 and op 200).
Similarly, the burden absorbed account was hit at each operation for ($.06 * 100) and
($.0375 * 100) respectively. In both occurrences, the labor/burden account was credited,
and the WIP account was debited.

• Since production was posted at the last operation (200), this signals the system that the last
operation of a product is completed, and a finished product has been produced. In the event
of a last operation, a second transaction (RCT-FG) will occur which will credit WIP
inventory and debit FG inventory, effectively moving the product to Finished Goods. The
RCT-FG transaction will occur for both credit and debit at standard cost. The 'actual' cost is
also captured, and any deviation from the standard cost will be reflected in the appropriate
'usage variance' account.
• Now that we have production of 100 pieces of item 10-1001, we will now show the
transactions for shipping this item. The below screen shot shows all the transactions that
occur by shipping 100 pieces of item 10-1001 to a customer at $.50 selling price / each.
Notice that the income statement account 'generic sales income' has a credit of $50.00 and
the balance sheet account 'A/R accounts receivable' has been debited at $50.00. Also, the
Cost of Goods Sold (COGS) accounts (labor, burden, material) have been debited for their
respective values, while the FG Inventory account has been credited for a similar amount.

• Now that we have received raw material, posted production of finished goods, and shipped
 those goods, we can proceed to post the GL to the ledger via the GL Posting Menu. Once
all the transactions have been posted, you can view the Ledger Balance Report to see all the
summarized values of the accounts. You can also click the 'detail' button beside the account
to see the itemized detail transactions that produced each account summary. The screen shot
below shows the Account Balance Report for all non-zero valued accounts.

• Finally, you can view a generic Income Statement by clicking on the Finance → Ledger
Reports → Income Statement menu. Clicking run will show the statement elements that
add or subtract from the Standard Margin (Sales less Cost Of Goods). Since the above
transactions were limited, the income statement is rather simple in this case, and is
essentially the sales minus the cost of goods sold. Elements that reduce the standard
margin...other than variance...are not directly involved in the production and therefore are
elements captured outside the receipt, production, sales functions present in the previous
automatic transactions. Elements such as engineering cost, marketing costs, G&A are all
captured explicitly by the accounting team each period.
11 Quick Cash Management (Personal Finance)

For small business or personal finance scenarios where in-depth financial mechanics are not
necessary, BlueSeer provides a trimmed down option of cash management transactions. Buying and
selling simple assets, managing recurring and miscellaneous expenses are all possible within the Quick
Cash Menu (navcode: cash). This menu provides a stream-lined entry mechanism for expense
recording and cash buy/sell transactions that do not require a lot of associative fields to support higher
level cross functional business visibility. The Quick Cash menu is primarily for data entry. There is a
browse/report menu for these transactions that can be viewed in Quick Cash Browse Menu (navcode:
cashb). The Browse menu consolidates all four types of entries in one browse screen and includes
charting of the transactions based on the date and type of transaction.

11.1 Quick Cash Navigation (navcode: cash)

There are four functional sub-menus within the Quick Cash entry menu. The functional menus
include 1) buying an asset, 2) selling an asset, 3 ) recording a miscellaneous expense, and 4) recording
a recurring expense. You can enter 'cash' in the navigation text-box on the menu bar to bring up the
Quick Cash entry screen. All four sub-menus are accessible within the main Quick Cash menu as
shown below :
Figure 10.1.1
11.2 Quick Cash (Buying Asset)
To record the purchase of an asset/item, click the 'buy asset' tab in the Quick Cash Menu. To add a
new purchase record, click the 'new' button. The 'buy' fields should become enabled. The Entity
drop down list contains the Vendor Master codes for your vendors. If there are no records in the drop
down list, click the 'add new vendor' button, and it will transfer you to the vendor master menu where
you can enter a vendor record. Note, you do not have to maintain a separate vendor for each asset you
buy. You can choose to create a generic vendor and apply all of your purchases to this 'generic' vendor
code. However, you do have to have at least one record in the vendor master. Having legitimate
vendors instead of a 'generic' vendor allows you to know more information about the vendor who you
purchased the item from, but it is not absolutely required. A generic vendor will do the job.
Now that you have chosen a vendor from the drop down list, you can enter remarks and a PO# if
you like (these are not mandatory). You can also change the date of the purchase by clicking on the
date dialogue box. This allows you to track when you purchased the item. There are three 'mandatory'
fields you must enter. You must enter an item description detailing the item you've purchased. This
will be used as the description applied to the auto-creation of the item in the item master that occurs in
the background. For example, entering 'black ball-point pen' will be captured in the item master for
this item even though the item number generated will be the next incremental number. Note: once
you've completed these steps and applied the purchase, an item in the item master (navcode: item) will
be generated for you and marked as type = 'asset'.
The other two mandatory fields are the qty and price. The price field must be entered, and it must
be a legitimate decimal number “no commas”. Once you've entered the price, you can tab to the qty
field. Typically, the default '1' in the quantity field should suffice in most situations, so you can just tab
to the 'tag/lot' field which is optional. Then click the 'add item' button. This will create a temporary
record in the table below the fields. The cursor will go back to the item description field for situations
where you have purchased more than one item, and you want to record all items on this one 'buy event'.
If you have no further items, you can click the 'commit' button at the bottom, and your purchase will be
complete.
Several transactions will occur behind the scenes upon committing. An item master record will
have been recorded in the item master along with establishing an inventory record of this item. The
appropriate financial ledger transactions will also occur, debiting you cash account and crediting the
inventory account for this item. Note, if auto-posting is turned on (the default is on), you will not have
to manually post these transactions to the ledger. The transactions will post automatically.
Once you have committed the transaction, the menu bar will indicate 'buy complete'. You can then
view the transaction in the Quick Cash Browse (navcode: cashb) menu. The images below show the
progression of entering the information for the buy menu and adding the item to the temporary table.
Note that in this example, we have created a 'generic vendor' entity to apply the purchase to.
Figure 11.2.1 (Buy transaction entering item, price, and qty)
Figure 11.2.2 (Buy transaction clicking 'add item' to add the item to the table (before commit)
11.3 Quick Cash (Selling Asset)
To record the selling of an asset/item, click the 'sell asset' tab in the Quick Cash Menu. To add a
new selling record, click the 'new' button. The 'sell' fields should become enabled. The Entity drop
down list contains the Customer Master codes for the list of customers you have previously established.
Unlike the 'buy asset' option where you do not explicitly have to have specific vendor codes for each
purchase, it is advisable to establish specific customer master codes for each sell transaction. The 'sell'
transaction will provide you with the option to print a receipt for the asset sold, and therefore the
customer's information will be provided on the receipt of the specific addressing information is created
for this customer in the customer master. If you have not previously set up the customer master
records, click 'add new customer' and you will be forwarded to the customer master menu to enter the
specifics of the customer you are selling the asset/item to.
The asset/item that is being sold must already exist in the item master, and the item must be an asset
type (code = 'A'). The 'item nbr' drop down list in the Selling Asset tab will contain all items from the
item master labeled as type 'A'. Choose from one of the items in this list and then tab to the next field.
The price field and the qty field are mandatory. Enter a legitimate decimal price (no commas). Tab to
the qty field and either choose the default value of '1' or enter a quantity. You are allowed to enter more
than is in inventory under the assumption that the inventory values may be inaccurate. Press the tab to
the tag/lot field (optional) and then click 'Add Item'. This will create a record in the table at the bottom.
You then have the option of entering another item to sell, or if you are only selling the one item, you
may click the 'commit' button to complete the transaction. Upon clicking the commit button, the
description on the menu bar should indicate that the selling transaction is complete.
Several transactions will occur in the background upon committing. The inventory for this item will
be reduced by the quantity entered in the qty field. Balanced financial transactions will occur at the
ledger with crediting the cash account and debiting the inventory account. A receipt of the transaction
may be provided to the customer purchasing the item. You can view the transaction and print the
receipt, if desired, in the Quick Cash Browse menu (navcode: cashb). The printer icon in the last
column of the browse table will provide a PDF print of the receipt. Note, only the 'sell' option will
allow the print icon to be shown in this column. The other three transaction types will show a lock
icon. The following images show the progression of creating a 'selling asset' transaction.
Figure 11.3.1 (Sell transaction entering item, price, and qty)

Figure 11.3.2. (Sell transaction clicking 'add item' to add the item to the table (before commit)
Figure 11.3.3 (Sell transaction clicking 'commit'. Menu Bar indicating 'sell complete').
Figure 11.3.4 Quick Cash Browse (navcode: cashb) showing the transactions. The 'sell' type
transactions will have a 'printer' icon in the last column that will allow a receipt to be printed or PDF
file created.
Figure 11.3.5: Receipt image of Sell Transaction. You can print and/or save as a PDF file.
11.4 Quick Cash (Expense Miscellaneous)
Recording expenses is one of the more repetitive financial transactions that most people want to
track. The Expense Miscellaneous tab allows you to capture those on the spot expenses that are not
considered 'recurring'. The Expense Recurring tab is used for expenses that are recurring on a monthly
or yearly basis.
To record a miscellaneous expense, click the 'misc expense' tab in the Quick Cash Menu. To add a
new expense record, click the 'new' button. The 'misc expense' fields should become enabled. Much
like the 'buy asset' tab, the expense miscellaneous menu allows you to track your expenses by vendor.
You can alternatively choose to create a single 'generic' vendor, but you must have at least one vendor
in the entity drop down list. The primary tracking method for expenses is determined by the expense
account you place the transaction in. You can create as many expense accounts as necessary to
distinguish and classify your expenses for reporting purposes. When you create a new expense
account, it is automatically created in the Account Maintenance under the Finance menu as an
incremental account number of type 'E' for expense with the description that you enter in the dialogue.
To create a new expense account, click the 'add account' button, then enter a description (classification)
for this account. As an example, you could enter 'office supplies' as the account description, and record
any expense associated with office supplies (pens, paper, ink, etc) against this expense account. The
more effort placed in creating appropriate account classifications, the more you will gain from tracking
and reporting your expenses for audit or tax purposes. It is advised that you consider your accounting
structure before recording your first entries. You can also go into account maintenance (navcode:
accm) and pre-enter your expected expense accounts. Expense electric, Expense water, Expense
phone, Expense maintenance are all good examples of separating your account structure and classifying
your expenses.
The Expense Description is a mandatory field. You must describe the nature of the expense in this
field. You can then tab to the expense account drop down list and use your up/down arrow key to
traverse the possible accounts. The description of the accounts are provided to the right as you key up
or down. Once you select an account, press tab and enter the price of the miscellaneous expense. This
must be a legitimate decimal value (no commas). Then, tab to the qty field and choose the default '1'.
In most instances, the default quantity of 1 is sufficient. Then tab to the tag/lot field and enter a value
(this field is optional). Click 'Add Item' to enter the transaction into the table at the bottom. You may
choose to enter another expense to the transaction by entering another description and repeating the
process. Once you have finished entering the expenses, click the commit button to record the set of
expense transactions.
You can view the expense transactions that you entered in the Quick Cash Browse report (navcode:
cashb). This browse/report tool is a date specific report and defaults to the beginning of the year to the
current date. You can change as necessary. All four types of transactions will be visible. You can also
click the 'basket' icon to see details of transactions or click the 'chart' button to see pie charts of the total
expenses for the date range (top chart) and total buy/sell transactions for the same date range (bottom
chart). The below figures shows the steps of entering a miscellaneous expense through to reviewing in
the Quick Cash Browse menu.
Figure 11.4.1: Entering a miscellaneous expense
Figure 11.4.2: Adding a new Expense Account Description
Figure 11.4.3: Adding expense items to the expense table before committing
Figure 11.4.4: Committing the expense
11.5 Quick Cash (Expense Recurring)
The Recurring Expense menu is very useful functionality for capturing and viewing monthly
expenses are common among all business verticals. This menu allows you to designate monthly
recurring expenses and to track whether or not you've paid those expenses on any given month. The
Calendar month is used for paid/unpaid designation. For example, if you have established any
recurring monthly expenses, at the beginning of each month, these expense records will be display as
unpaid (visible x). Any time during the month, you can mark these expenses as paid, and they will
remain paid (visible checkmark) until the first day of the next month. Along with the visibility cue, a
history of each recurring expense is provided in a table at the bottom of the menu for convenience
labeled 'History of Payment'.
To register a recurring expense, click the 'recurring expense' tab in the Quick Cash Menu. The
entity drop down list should be set up with a list of the vendors for each of the recurring expense. You
should create these before you register your recurring expense so that you can associate the appropriate
expense with the appropriate vendor. You can go to the vendor master maintenance menu (navcode:
venm) to set up your vendor codes. Choose the appropriate vendor code and enter a value in the unique
ID field. You can enter 'electric' as an example. Then enter a description of this expense in the
description field. This is a mandatory field. You then choose the appropriate expense account to
register this expense to. If you have not already created your expense accounts, you can click 'add
account' and enter a description of the account. It will automatically be added to the list. Then enter a
legitimate 'monthly' value in the price field of the expected expense. Click 'Add Item' and the item will
be registered in the table at the right of the menu. The figure below is an example of registering the
expense record.
Figure 11.5.1: registering recurring expense record.
Figure 11.5.2: Table showing registered recurring expense after clicking 'add item'
 Notice from the above figure that the 'ThisMonth' column is marked with a red x. To pay this
expense, simply place the dollar amount of the expense in the second to last column labeled
'ExamtAmt' and click on the checkbox in the last column. You can do multiple records in this same
pattern at one time. Once you've clicked the expenses that you wish to pay and have entered the exact
values of the expense, click the 'pay selected items' button at the bottom of the menu to commit these
payments. The following figure shows the screen after paying the expense. Note: once the expense is
paid for the month, you will not have the opportunity to pay this again until the first day of the
following month as the last column will become disabled until then. You can also click on the first
column (flag) to show the payment history of this expense in the table at the bottom of the menu.

Figure 11.5.3: Recurring expense after selecting to pay this expense for the month.
 Once you have registered all of your recurring expenses, you can revisit this menu once a month to
pay/track your monthly payments. A summed total of all recurring cost for the month is provided at
the bottom of the menu as well as a placeholder for your monthly income. Simply add your expected
monthly income in the income field, and click 'update income'. You can change this at any time. A
difference field is provided for convenience between the monthly income and monthly expenses.
The below figure shows the payment history for this example as well as the total recurring amount,
monthly income, and difference.

Figure 11.5.4
11.6 Quick Cash Browse (navcode: cashb)

The primary reporting tool for the Quick Cash Transactions is the Quick Cash Browse Menu. All
four type of transactions can be viewed in this menu for any given date range. The default date range is
the beginning of the year to the current date. Simply click 'run' and the report will generate all
transactions that have occurred between the from and to date range. The initial report will show each a
summary of these transactions. You can click on the 'basket' in the left column to see the details of
each summary transaction (in situations where you committed more than one item per transaction. To
close the detail menu, click the 'hide details' button. You can also view pie charts of the expenses and
buy/sell transactions. Click the toggle box labeled 'charts', and the chart menu will appear. The upper
pie chart is the combination of recurring and miscellaneous expenses for the given date range. The
bottom chart is the total buy/sell transactions that have occurred for the given date range.

Figure 11.6.1: Quick Cash Browse (Expense and Buy/Sell Pie Charts).
Figure 11.6.2: Quick Cash Browse (Summary Table).

12 Engineering

12.1 Engineering Change Maintenance (navcode: ecnm)

To Be Added
13 Quality

13.1 Quality Problem Report (navcode: qprm)

To Be Added
14 Human Resources

14.1 Employee Maintenance (navcode: empm)

BlueSeer provides a human resources module for managing employee information. The employee
maintenance record for each employee drives much of the functionality within the HR master menu
(including Time and Attendance and work shift associations), and as such should be set up correctly to
ensure proper execution. There are two pre-requiste maintenance screens that need to be setup before
adding an employee record. You need to add at least one record to each of Department Maintenance
and Shift Maintenance . To add or edit an employee record, go to 'HR'|'Employee Maintenance' menu.
Click the 'New' button, and enter a unique employee number. The employee number can be up to 10
characters. The employee number should be unique to each employee. If bar-coded badges are
provided to the employees, it is recommended that this number on the bar-coded badge be the same as
the employee number for convenience when using the timeclock functionality (scanning in/out). When
all fields are completed, click the 'Add' button to commit the employee record.

NOTE: the employee maintenance and user maintenance are two separate menus and are independent
of each other. Establishing one does not establish the other.

You will need to choose a type for the employee. BlueSeer currently supports three types (Hourly,
Salary, and Temp). The type field is used in time clock functionality, reports, and other application
logic relative to HR functionality. There is also an 'active' versus 'inactive' drop down list to indicate
whether the employee is an actual current employee or has been terminated for whatever reason. Some
reports use this active/inactive flag to filter records from being displayed.
The Department field is also mandatory. An employee can be assigned to one and only one
department/cost center. Choose the appropriate department for each employee.
The last mandatory field in the employee setup is the Shift. You will need to assign the employee to
a predefined shift. Shift records are defined in 'HR'->'Shift Maintenance' and can be viewed in the
Shift Browse Menu. Each employee can be assigned to one and only one shift. You can create as
many shift records as necessary to support the various operational hours of the business.
All other fields are optional and will appear on various reports and may be applicable in further HR
functional logic. You will need to fill these fields with appropriate values as necessary.
Figure 13.13.1 shows a screen shot of the Employee Maintenance screen and the fields associated with
this menu.
Figure 14.1.1
14.2 Shift Maintenance (navcode: site)

The shift maintenance menu maintains the various shift records that are necessary to support the
operational business hours of the business. Each employee is assigned one and only one of the shift
records defined here. The time clock functionality within BlueSeer depends heavily on the defined
shifts and the association of the shifts which each employee that utilizes the time clock menu. Entering
a new Shift record is fairly straight forward. Go to the Shift Maintenance menu under the HR master
menu. Click the 'New' button, and enter a shift ID. The shift id can be any value up to 8 characters.
Enter a description to go along with the shift id and then proceed to enter the appropriate time values
for each of the 7 workdays. If Saturday and Sunday are not work days, then leave as the default
“00:00” for both beginning and ending. Once you have entered these values, click 'Add' to commit the
record.
Figure 13.2.1 shows a screen shot of the shift maintenance menu.

Figure 14.2.1

14.3 Time Clock Management and Maintenance (navcode: time)

BlueSeer provides a time clock menu to track employee clock in and clock out events. The time clock
menu can be found under the "HR" menu in the menu bar. The time clock package provides a working
"clock entry" screen, a means to adjust timeclock entries, and various reports to support payroll entries
and analysis. Each employee's time clock 'ID' is their corresponding employee ID which must be setup
first in Employee Maintenance before the clock entry screen can be used.
As mentioned previously, each employee has to be setup in the Employee Master. The ID associated
with the employee is provided to the employee for their use in interacting with the time clock entry
screen. The employee can either enter the ID via a keyboard...or it can be imprinted on an employee ID
badge with bar-code...and subsequently scanned with a bar-code reader. Figure 13.3.1 shows the time
clock menu that will be visible by the employees.
Figure 14.3.1.

The 'ClockNumber' has focus at all times for either keyboard entry of the employee's clocknumber
or bar-code scanning of the clocknumber.

The typical deployment scenario is to deploy BlueSeer on a stand alone PC where it can be
appropriately accessed by the employees. The PC should have a keyboard and/or barcode scanner
depending on whether or not the employee ID is barcoded on their employee ID card. You can launch
BlueSeer on the target PC, click on the TimeClock Entry menu, and leave this menu in the foreground
at all times for use by the employees.

The "ID" field always has focus, so all the employee has to do is select in the dropdown list
whatever the appropriate event is (Clock In or Clock Out) and enter their ID via the keyboard or scan
their card. If it is a 'clock-in' event (and they haven't already clocked in) then a successfull 'image' will
appear (see figure 13.3.2 below).
Figure 14.3.2
If for any reason the entry was not successful, a message will appear indicating so (example: bad ID,
already clocked in, etc) (see figure 13.3.3 below).

Figure 14.3.3

The image notification will pause for 2 seconds before resetting for another entry event. (You
generally do not have to reset the dropdown type event since your employees are generally all clocking
in or all clocking out depending on shift). A text field below will contain a record of last entries that
includes timestamps, ID, and name of employee.

14.3.1 TimeClock Accounting

Each timeclock entry event records the real time (Tr) and accounting time (Ta) of the entry. Ta is
recorded on quarter hour intervals. For example, if an employee clocks in at 8:03AM then the (Tr) time
will be 8:03AM and the (Ta) time will be recorded as 8:00AM. However, if the employee clocks in at
8:09AM, then (Ta) will be 8:15AM. There is a 7.5 min window within every quarter hour that dictates
whether (Ta) is assigned forward or backward. (Ta) accounting time is provided to make it easier for
payroll entries and reporting. However, the real clock time Tr can be reviewed any of the TimeClock
reporting menus for administrative and management purposes of employees real time labor activity
(example: on time versus tardy reporting and disciplinary actions).

14.3.2 AutoClock Maintenance and Procedure

The AutoClock maintenance utility is a procedure that can be executed once a week that will
generate exceptions for missing clock records in the absence of an employee specific clock event. This
utility is generally ran on a monday following the work week under review. The menu can be found
under 'HR'|'TimeClock Menu'|'Administration'|'AutoClock Maintenance'. The procedure is simple. Just
enter the number of days 'back' you want to check for missing TimeClock events and click the submit
button. If any exceptions are found, time clock records will be generated for any employee that is both
active and has the 'autoclock' checkbox checked in their employee master record. The clock records
will be compared to the employee's shift schedule and if any periods are found without a corresponding
timeclock record, a new record with code '66' will be generated. Supervisors and/or HR can then
review these '66' records with employees and ascertain the reason for the absent timeclock record.
They will then adjust the '66' records to whatever payable or non-payable code by using the Supervisor
Approval Menu (see 'HR'|TimeClock Menu'|'Administration'|'Supervisor Approval'). As stated before,
this procedure is typically done on a Monday following the week in review and adjusted in time for the
upcoming payroll event. Note: The autoclock procedure should be ran by an administrator or key
supervisor. This procedure can also be set as a background service to be automatically executed on a
scheduled frequency. (Cron How-To to come)

14.3.3 TimeClock Code Maintenance (navcode: tima)

TimeClock Code Maintenance (under 'HR'|'TimeClock Menu'|'Administration'|'TimeClock Code
Maintenance') allows you to create codes that describe various employee clock events. There are 5
codes that are system codes (these cannot be deleted or edited). The remaining codes are miscellaneous
codes that your management team can apply to various scenarios of work scheduling and/or absent
explanations. There are reports where you can review the frequency of timeclock events by code which
can be used to review employee's consistency in their work schedule or lack there of. You can add
codes as necessary. To see a complete list of codes go to 'HR'|'TimeClock
Menu'|'Administration'|'TimeClock Code Browse' menu. You can then click on a specific code to edit
or review it's description and use. Note: You can set these codes as 'Payable' or 'Non-Payable'
depending on the code's usage.

14.3.4 TimeClock Accounting Codes

Code Descr System Code
00 Successful in/out event yes
01 Timeclock in event only yes
02 Bereavement - Unpaid
04 Jury Duty - Unpaid
06 Vacation - UnPaid
07 Lack of Work - UnPaid
13 Early yes
14 Tardy yes
16 Alternate Schedule yes
20 Medical Leave
21 Other UnPaid
23 Holiday - UnPaid
24 Holiday - Paid
25 FMLA - UnPaid
27 Disciplinary Layoff - UnPaid
66 Exception Pending Review yes
96 Termination
15 Administration

15.1 Class (Panel) Maintenance (navcode: panel)

The central design theme behind BlueSeer is 'JPanel' centric. Each maintenance panel (and most
reports) have a unique JPanel that the display and logic reside in. Each JPanel is a separate java class,
and it is necessary to register each panel 'class' within the BlueSeer database. This is by design to make
it as simple as possible to add new functionality or new customization to BlueSeer. Adding a new
'maintenance menu' is as simple as adding a new JPanel class with appropriate fields and logic,
compiling and dropping it in the BlueSeer source directory, and registering the new class with in the
Class Maintenance Menu. For example, if you wanted to add a menu called 'Job Data Entry
Maintenance' for end users to enter data for a particular job, you would create the JPanel with the
appropriate fields and logic and include in the BlueSeer directory. From NetBeans, you would most
likely right click one of the other 'maintenance panel' .java files, copy, right-click the parent 'BlueSeer'
directory, click 'Paste' → 'Refactor Copy', Rename to 'JobEntry.java' and NetBeans will include your
new class in the BlueSeer Source directory. You then simply have to register 'JobEntry' in the Class
Maintenance registration menu.
To add a new class (JPanel), go to 'Class Register' under the Admin master menu, click on 'New' and
enter the 'class id' field with the new JPanel class name (leave off the .class or .java extention). You can
add an optional description as well. If this is indeed a GUI JPanel to be used as an interactive
maintenance menu, you will need to check the 'BlueSeer Core Panel' box. If it is an arbitrary utility
class, then leave that field unchecked. A screenshot of the Class Maintenance menu is provided below
in Figure 14.1.1.

Figure 15.1.1
15.2 Menu Maintenance (navcode: menu)
All of the maintenance, browse, and report menus within BlueSeer are stored in the database by menu
name. Each menu parent and menu item in the master menu bar are stored in the database by name.
This setup facilitates the creation of new menus and/or the customization or regrouping of menus under
different hierarchies. The one exception to this is the master menu bar. All the parent menus on the
master menu bar are permanent by design and cannot be changed. All inherited sub menus of the
master menus can be added, updated, deleted, and/or re-positioned. The registration of a menu into the
database is a simple step. To add (or update) a menu, click the Menu Maintenance menu under the
Admin master menu. You can either add a new menu or update an existing menu by clicking on the
search button and browsing for the menu to be updated. To add a new menu, click 'New' and enter a
menuID value. This can be any value (you will assign to the tree in Menu Tree Maintenance) up to 30
characters. You can then optionally add a description if necessary to describe the menu. You must
enter a ClassID, which is the JPanel class that is used by the menu for interaction. JPanel Class were
registered previously in Class (Panel) Maintenance. You do not have to enter a ClassID if this menu is
a 'parent' menu and is for navigational use only. If a 'parent' menu only, check the 'Parent Menu Only?'
toggle box. In this case, you can leave ClassID blank. You will also need to enter a 'NavCode' that will
allow navigation to the menu via the navigation textbox on the menu bar. This field is validated and
will ensure a unique navcode per menu. Once this is complete, click 'Add' to commit the new menu to
the database. Figure 14.2.1 shows the screenshot of the Menu Maintenance screen.

Figure 15.2.1
15.3 Menu Tree Maintenance (navcode: tree)
The menu tree maintenance routine maintains the menu registration and positioning within the
master menu bar in BlueSeer. To place a new menu within the tree (assign to a parent within the master
menu bar), you must first confirm that you have registered the menu in Menu Maintenance, and
therefore registered the Class that the menu is associated with in Class (Panel) Maintenance. Once
these two items are complete, you can then proceed to insert the menu within the Tree. Click on the
Menu Tree Maintenance menu within the 'Admin' menu. This will bring up the Menu Tree
Maintenance screen. The screen shot below (Figure 14.3.1) shows the menu when it is first initiated.
Figure 15.3.1

The 'root' node of the tree is fixed as are the immediate children of the root node (I.e...Address,
Purchasing, etc). These menus cannot be changed or adjusted. You can, however, add, update, delete,
or re-position submenus to these parent menus. You can click on any menu in the right panel and the
fields on the left will be occupied with the tree position information for that menu. For example,
clicking on the Address menu in the right panel will produce Figure 14.3.2.
Figure 15.3.2

You will notice that the Parent Item of the 'Address' is valued as 'root'. The component is the active
menu in question 'Address'. The 'Name' field is the name of the Address menu that you see when you
open BlueSeer and view the Master Menu Bar. You can change the value in the 'Name' Text Box to be
whatever you want. The 'Component' drop down text box is the exact MenuID that was registered in
Menu Maintenance. There are two types to choose from with regards to the menu type (Jmenu and
Jmenuitem). If it is a navigational parent (as Address is indeed so) then the type should be “Jmenu”.
Otherwise the type should be “Jmenuitem”.
So, as an example of adding a menu, let's add a 'test' menu item (jmenuitem type) to the 'Address'
parent menu. Right-click on the Address Tree to open it's children. Then click on the last child item
under the Address menu (“LabelMenu”). This will place 'Address' in the 'Parent Item' text box. See
Figure 14.3.3 below.
Figure 15.3.3

With the screen active as witness in figure 10.3.3, click inside the Component drop-down list and
add the MenuID of the menu you wish to add (assume you registered the menu 'TEST' in Menu
Maintenance). After entering 'TEST' in the Component drop-down list, press the Tab key. You will
notice that the Index field converts to '-1' and is disabled as it should be. You can then enter the 'Name'
of the menu that you wish to be visible on the Menu Bar. You can enter 'TEST' or 'TEST SCREEN' or
whatever you wish. Then, choose JmenuItem from the 'Type' drop-down list. You can leave Icon,
Initvar, and Function blank (these are discussed below). Check the 'visible?' and 'enable?' boxes with a
check mark for both. You can then click 'Add' to insert the new menu item into the tree. Figure 14.3.4
below shows a screen shot of the menu just after clicking 'Add'.
Once you've inserted the new menu, the Menu Tree Maintenance window will refresh with the new
information. However, the actual menu 'TEST SCREEN' will not appear under the 'Address' menu
until after you have closed BlueSeer and restarted. The menus (and security access thereof) is assigned
once at startup of the BlueSeer application. Any changes to the menus (or security) must be
accompanied by a restart of the application.

15.3.1 Field Definitions:

• Icon: The icon text box is reserved for providing an icon image file instead of 'verbiage' for the
menu name. The 'Home' (little blue house icon) is an example.
• InitVar: This text box is used for intializing a function within each menu class “initvars(string
var). This function should be assigned in every menu class created. Assigning a value of '1' in
InitVar will execute the initvars function within the class. If the value is blank, it will not be
executed.
 • Function: A few of the menu items are functions only...i.e. They do not have interactive Panels
for which data is entered or retrieved. These type of menus simply perform a simple function or
similar background activity. Assigning a '1' in the Function text box will flag this menu item as
a 'function' with no visible panel for interaction.
• Visible: Checking this box will ensure that this menu item is visible at startup (assuming you
have permissions).
• Enabled: Checking this box will ensure that this menu item is enabled. The menu item can be
visible yet disabled as an option.

Figure 15.3.4
15.4 Site Maintenance (navcode: site)
A default site is created during the installation of BlueSeer. The site code is '1000'. You can view
this site under the Admin Menu by clicking on Site Browse and then clicking the appropriate select
option from the table. You will be redirected to the Site Maintenance Screen. You can also enter your
own Site code by going to the 'Admin' menu and then choosing Site Maintenance. Click 'New', and
enter a site code of your choice. The site code can be a maximum of 10 characters. Enter the
appropriate information for the site address and then click 'Add'. Figure 14.4.1 shows a screen shot of
adding a new site code. Once this code is entered, if you choose to use this code as your default site
code, then you must enter this code in Default Maintenance under the 'Admin' menu. Go to the Default
Maintenance menu, enter the code, and click 'Update'. This will commit your new site code as the
default site code for all functionality within BlueSeer. Figure 14.4.2 shows the updating action within
the default maintenance menu.

Figure 15.4.1
Figure 15.4.2
15.5 User Maintenance (navcode: usrm)
Adding and updating user accounts is provided for in the User Maintenance menu under the Admin
menu. Note: User Ids and Employee Ids are not the same and are independent fields with their own
unique purpose. The user maintenance menu allows you to maintain the users ID and associated
information with usage of the BlueSeer application. The userid is prevalent through the application in
usage and visibility. The majority of the functional modules use the userid field to stamp an id onto
each record that is created and/or updated for tracking and change purposes. Each user of BlueSeer
should have one and only one userid so that change management can be controlled and audited as
necessary.
To create a new user, go to the user maintenance menu under the Admin master menu. Click the
'New' button. This will enable the fields for input. Enter in a unique value for 'userid'. This can be any
string up to 8 characters. You can then proceed to enter the associated information including lastname,
firstname, email account, etc. The password field is used by the admin to establish and change
passwords as necessary. Once the required information has been entered, click the 'Add' button to add
the userid to the database. You can then provide the user with the application, userid, and password.
However, you still need to add 'permissions' to this userid (which is discussed in the next section). A
screen shot of the user maintenance menu is provided in figure 14.5.1.
Figure 15.5.1
15.6 User Permissions Maintenance (navcode: uspm)
Once you have created a unique user id, you can then assign permissions that will allow the user id
in question to access certain menus within the application. To assign and/or update menu permissions,
click on the User Perms Maintenance menu under the Admin master menu. This will bring up the user
perms maintenance screen. There are four panels in this menu screen. The majority of the time, you
will assign individual menus to specific user ids. This is achieved by the panel marked 'Menu To User
Assign/Unassign'. Simply choose the menu in question from the drop-down list and choose the user id
from the user drop down list, and then either click the assign or unassign button to associate or
unassociate the menu to the user id. You can also copy one user id permissions to another in the panel
marked 'Copy All User Permissions'. This is the most feasible for new implementations. The standard
practice is to create 'general' user ids for groups of functionality...(by Finance, Customer Service, etc)
and assign relevant menus to these generic user ids. You can then use these ids to copy permissions
from and assign to 'real' user ids as they are granted access to the system.
Note: the 'admin' user id can not be 'assigned' to in the 'copy all' panel for security purposes. Once a
new menu is created/registered in menu maintenance, it is by default assigned to the 'admin' user id
automatically.
To view what menus are assigned to what users, you can see this list in 'Menus Assigned to this
User' panel. Choose a user id in the drop-down list and click the relevant 'get' button.
To view all users assigned to a certain menu, the far right panel 'Users Assigned to this Menu' will
provide that detail. Simply choose a menu in the drop down list and click the 'get' button. A screen
shot of the User Perms Maintenance menu is provided in Figure 14.6.1.
Figure 15.6.1
15.7 Printer Maintenance (navcode: prnt)
Printer Maintenance is primarily used for maintaining configuration of label printers. Most non-
label printing functionality (reports, tables, etc) is handled by the default printer dialog box of the
jasper viewing window. Typically, reports and custom prints are processed by the default printer
dialog box of the operating system. The label printing functionality, however, is specific to the printers
set up in this menu.
The configuration of the printer maintenance is fairly simple. A printer 'code' is defined for each
label printer along with it's specific IP address and Port. A type field is provided with only two options
at this time 'LASER' and 'ZEBRA'. Most label printing configurations wil be 'ZEBRA'. To add a new
printer, click the new button and enter a code for the printer. The code can be no more than 8 chars
long. Enter a description, IP address and Port number and click the add button to commit the record.
See figure below for screenshot of the printer maintenance panel.
Note: any label printer that supports ZPLII printer commands will work. In these cases, you can
assign 'ZEBRA' to the type, even if it's a different manufacturer.

Figure 15.7.1
15.8 Label Maintenance

BlueSeer can generate container, address, and item labels from thermal label printers of the
appropriate type. The label template design is left to other 3rd party tools, but once the label template is
created and stored in the template directory, it can be used to print various labels. Note: at this time,
only ZPL coded templates are supported, so it is imperative that you design your templates based on
ZPL supported printers. There are several label designer software vendors that offer free downloads
that can be used to generate the label template. ZebraDesigner® and Bartender Label Software® are
two such packages. Once you've created the template, place the template file in the blueseer/zebra
directory. There are already several generic templates in this directory as shown in figure 14.8.1.
Figure 15.8.1

An example of the content of the generic address label template file is shown below. Note that the
content is essentially comprised of ZPL specific codes for printing the desired template and are generic
to ZPL based printing in general. However, in order to overlay 'data' onto the desired location, you will
need to use variables which can be defined with a $ prefix. For example, the Address label below
passes a value to the '$ADDRNAME variable highlighted in yellow (see below). When you design the
label, place your 'variables' in the appropriate text boxes with a prefix $ character. Note also that the
java program calling the label is designed specifically for the variables created in the ZPL template file
so any custom labels with custom variables must have a corresponding custom java program to drive
the label generation. See the source code for the java class com.blueseer.lbl.LabelAddrPanel to
understand more about the correlation between the java program and the label template file.
Figure 15.8.2 (Contents of address.prn label template file)
#CT~~CD,~CC^~CT~
^XA~TA000~JSN^LT0^MCY^MNW^MTT^PON^PMN^LH0,0^JMA^PR4,4~SD15^JUS^LRN^CI0^
XZ
^XA
^MMT
^PW812
^LL1218
^LS0
^FT372,1197^A0B,62,62^FH\^FDTO:^FS
^FT612,363^A0B,54,52^FH\^FD$ADDRZIP^FS
^FT611,692^A0B,54,55^FH\^FD$ADDRSTATE^FS
^FT532,1066^A0B,51,52^FH\^FD$ADDRLINE2^FS
^FT613,1070^A0B,56,57^FH\^FD$ADDRCITY^FS
^FT454,1065^A0B,54,52^FH\^FD$ADDRLINE1^FS
^FT374,1063^A0B,51,52^FH\^FD$ADDRNAME^FS
^FT78,1189^A0B,62,62^FH\^FDFROM: $SITENAME^FS
^FT41,187^A0B,28,28^FH\^FD$TODAYDATE^FS
^FT786,120^A0B,28,28^FH\^FDBlueSeer^FS
^FT237,990^A0B,28,28^FH\^FDph: $SITEPHONE^FS
^FT186,984^A0B,28,28^FH\^FD$SITECSZ^FS
^FT134,987^A0B,28,28^FH\^FD$SITEADDR^FS
^PQ1,0,1,Y^XZ
15.8.1 Address Labels (4x6) (navcode: lbla)
Address labels can be generated from BlueSeer. To generate an address label for a specific customer
ship-to address, enter 'lbla' in the navigational text-box on the main-menu bar. Note: This menu only
prints labels for Customer 'shipto' codes. You need to confirm that you have a ZPL compatible printer
set up in printer maintenance (navcode: prtn) before proceeding.
To print the label, choose the bill-to code parent of the ship-to code that you want to print a label for.
Then click the button below to get a list of possible ship-to codes that are applicable. Select the target
ship-to code and the target printer. The address will be displayed in the Address text box. If the
address presented is the one to print, then simply click print and a single label will be printed to the
printer assigned.

15.8.2 Container Labels (4x6) (navcode: lblc)

Container labels can be generated from BlueSeer. Container labels are specific to a customer order
and customer line of that order (a single item). The container label print program can be accessed by
entering 'lblc' in the navigational text-box on the main-menu bar. You will first need to confirm that
you have a ZPL compatible printer set up in printer maintenance (navcode: prtn) before proceeding.
To print the label, enter the sales order number, line number on the order, quantity (per container
label), number of labels and reference and lot numbers (both optional). If the information entered is
correct, a 4 x 6 generic container label will be generated for that specific order / line number.
Note: It is possible to design and print a custom label. Once the custom label has been defined in
Label File Maintenance, the code used for the label can be assigned to specific customers. The 'Label'
drop down selection box in Customer Maintenance can assign a specific custom label to all container
labels for this customer's orders. The association is only at the customer bill-to level and not the ship-
to level.
Figure 15.8.3

15.9 Label File Maintenance (navcode: lblm)

Label File Maintenance is used to manage the label template files found in the blueseer/zebra
directory. You can design and create custom ZPL formatted labels for containers, addresses, or items.
Once the template has been designed and placed in the blueseer/zebra folder, you will need to associate
a code with the custom label. Enter a label code (8 chars max) and the name of the file placed in the
blueseer/zebra directory. Then choose a type of label and click Add to commit the record. You can
then use this code to assign specific customers with this new custom label in customer maintenance
drop-down field 'Label'.
Figure 15.9.1
15.10 Cron Maintenance (navcode: cron)

As of version 6.3, BlueSeer comes with a simple scheduling class that can be executed as a
background service and provides the capacity to schedule application execution at specific dates and
times or when there is a need for a job to run in a recurring theme. The schedule is based on the cron
scheduler which is a construct in the unix/linux world for scheduling execution time of jobs or tasks.
The windows counterpart of the cron scheduler is the task scheduler. This cron mechanism offered
here in BlueSeer is independent of the Operating System cron or task scheduler.
The cron service provided by BlueSeer is a continuously running background job that is executed
separately, and in addition to, launching the GUI application. To launch the service, you can type the
following in a DOS command prompt in Windows :
c:\BlueSeer\jre17\bin\java -D"java.util.logging.config.file=bslogging.properties" -cp
".;c:\BlueSeer\dist\*" utilities.cronServer
Typically, a windows service would be created to launch the above command as a background
service. The command for linux is essentially the same. For linux environments, you can add the &
control operator flag at the end of the command to launch the cron service in the background as shown
below.
/home/yourdir/blueseer/jre17/bin/java -D"java.util.logging.config.file=bslogging.properties" -cp
".:/home/yourdir/blueseer/dist/*" utilities.cronServer &

To create jobs to be executed by the cron service, go to the Cron Maintenance menu under the
Admin main menu. You can also go directly to the menu by typing 'cron' in the navigation text-box on
the main menu bar. Figure 14.10.1 shows the form for creating new cron service jobs. To enter a new
job, click the new button and enter an arbitrary name for the job number. The description and group
fields are both arbitrary. The group field is used by the service to group similar jobs. The job class
drop-down field governs the behavior of the job and must be pre-defined, compiled, and in the java
class path. These job classes are registered in Generalized Code Maintenance. New job classes can
be defined and registered as necessary as shown in Figure 14.10.2. The key used in Generic Code
Maintenance must be 'sys_job_class' to be registered correctly.
A specific Job Class is the JobSys class. This class allows for specific automation of application
events that are typically scheduled as a recurring event. The following represent the current functions
that can be scheduled with the JobSys class. These values must be entered in the parameters field
along with choosing JobSys in the Job Class drop down:
1) postgl (Post the GL Transactions to GL History)
2) edi (governs the EDI Processor for automated EDI processing)
3) edi810o (Exports non-exported Invoices in BlueSeer as X12 810)
4) edi856o (Exports non-exported ASNs in BlueSeer as X12 856)

The parameters field is also used to pass values to other job classes. For example, entering an AS2
id (as defined in AS2 Maintenance) in the parameters field when using the jobAS2 job class will
execute a job for that specific AS2 trading partner. You can create a cron job for each AS2 trading
partner in this manner and effectively schedule their file transmissions independently of other AS2
trading partners. If you create a custom job class, you can use the parameters field to pass values to
your job class and distinguish job ids (per parameter) accordingly.
The priority field is arbitrary and is used to set priorities within group cron events for job ids that
have the same group.
The Expression field governs the timing and schedule of the job being created. The expression
field uses a 7 field expression group (minimum of 6) to determine the execution schedule. The below
table 14.10-A is borrowed from the quartz library documentation and provides the necessary detail for
each column usage. Each column represents a specific time variable. For example, to execute a job
every 2 hours of every day, the expression would be :
0 0 0/2 * * ?
Note: The expression field in the Cron Maintenance menu is mandatory and is validated for
correctness before committing as a record. For more detailed examples of expressions you can use, go
to the documentation page of the Quartz java library at http://www.quartz-scheduler.org/documentation.
After entering the necessary info to create the new job record, click the add button which will
commit the record to the database. The job will not execute however until the job service has been
started as discussed above. Once the job service is started and executing jobs, the service uses a
watchdog process that monitors job entries for any changes to the scheduling every 1 minute. If it sees
a previously defined job that is running, it will stop that instance and execute the new job with the new
scheduled expression. You can also stop a job from firing on it's next event by unchecking the
'enabled' checkbox for the specific job record. If the checkbox is unchecked, the job will be removed
from the queue on the next 1 minute watchdog cycle and cease to execute.

Table 14.10-A
Mandatory Allowed Values Special Characters Allowed
Seconds Yes 0-59 ,-*/
Minutes Yes 0-59 ,-*/
Hours Yes 0-23 ,-*/
Day of month Yes 1-31 ,-*?/LW
Month Yes 1-12 or JAN-DEC ,-*/
Day of week Yes 1-7 or SUN-SAT ,-*?/L#
Year No empty, 1970-2099 ,-*/
Figure 15.10.1

Figure 15.10.2
 15.11 PKS Maintenance (navcode: pksm )

BlueSeer provides a menu for maintaining and registering X509 public certificates as well as a
location to generate private keypair objects and pkcs12 formatted storage files (.p12). The records
registered in the PKS menu are used as reference keys in several other menus such as EDI Control and
AS2 Maintenance. When adding new records to the PKS menu, the fields that are enabled are driven
by the option selected in the type drop-down selection box. There are three types supported in this
menu (pem, store, keypair), and depending on your selection, various fields will be enabled and/or
disabled.
The pem option in the type box is used primarily to register and store a reference to a pem formatted
X509 certificate provided by a third party entity or trading partner. The X509 certificate is typically a
public key provided by the third party for use in encryption and signing mechanisms. The certificate is
usually delivered in a file with a .cer, .key, or .pem extension. The .cer files are typically text files that
contain the public key of a third party entity similar to what is shown in figure 14.11.1 below.
Figure 15.11.1
-----BEGIN CERTIFICATE-----
MIIDPzCCAicCCgHlbzvx4WGGAX8wDQYJKoZIhvcNAQELBQAwYTELMAkGA1UEBhMC
VVMxCzAJBgNVBAgTAlNDMQ8wDQYDVQQHEwZEaWxsb24xIzAhBgkqhkiG9w0BCQEW
FHN1cHBvcnRAYmx1ZXNlZXIuY29tMQ8wDQYDVQQDEwZic3Rlc3QwHhcNMjIwODIz
MTcwOTMxWhcNMjgwODIzMTcwOTMxWjBhMQswCQYDVQQGEwJVUzELMAkGA1UECBMC
U0MxDzANBgNVBAcTBkRpbGxvbjEjMCEGCSqGSIb3DQEJARYUc3VwcG9ydEBibHVl
c2Vlci5jb20xDzANBgNVBAMTBmJzdGVzdDCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBAIp+CYMixuQBWlbfuaV+hv8eU3pCMXGcvx2pLYTg1wkjaHH/eqlL
/VCizjPVCOhgbzJ0uAAWLmL/6HeLMNiTYpZoD1SSaPzwOcLWx+ZoBSsgc/mVpCZ0
bwLxj6ZHLEfooFXWm9g8552w3j+9tA7WRK1uTD/qy8PhhYKb8mV44O/+MxFTqIBK
u4H4o2yg2O6nRMpzspAHwzyIzF+Dy58TKibgWp0TDg5WunwWp3nfpBa304up2tOb
5QnBapWn59/onsm1Ax3Y9cGSuFBaPiDRH47cska2QH3LQ5q3SXLEN4rsWALynx6G
CUILa9IdTcAlrN8y2Y1slEN1RpbE8fUnLIkCAwEAATANBgkqhkiG9w0BAQsFAAOC
AQEAiQWXtoFZZiNsiGXVV8ps38Q+KV6I06/3RvJdCBe2qzeC2I2mYftG2jS7pZrR
hkygnl/qb3rhl68uHrWwomk8FX8OX3iNj85oHV1aMdcFlxY9KE8DYxZBUVQZlm9z
316NMS3O0BOZEM6HGqweOTTJzI8MPw+W959UcrZ8HI+lvtl9zNpncKl6S21HXFQ1
LB2kPeR3OO8kCK5pq5ADV8MZEGYKNkNxxRTyqRpRw/o0LTAuqfcuSCr3oyAlfhw1
TLK/tdUGvMibF6lKVHad2ceEV9e3YtijAcuXL4U5CHixdzKltc+wFZ0jdXNqKXc/
BesX2kh5BtL4Fb1TGGIsrjGMYQ==
-----END CERTIFICATE-----

The File text-box field will be enabled when you select the pem option in the type drop-down. This
field represents the file location where you stored the file. This is a validated field as the system will
confirm that the file does indeed exist when you attempt to add the record. Entering a pem record is
simple. Click the new button and enter an arbitrary key value that represents this record. Then enter a
description and a file location. The click add to commit the record. You cannot update a record once
added, however, you can delete the record and add a new one with the updated info.
The store option in the type drop-down is used primarily as a storage file for private/public keypairs
that are system generated. The BlueSeer install comes with a test store location. However, you are
encouraged to create a new store pks record after the installation. The store record is essentially a
reference to a .p12 file that you name in the File text-box field. Upon clicking the add button, the
system will create the file in precisely the naming convention (directory + filename) that is recorded in
the File text-box field. You will also have to enter an arbitrary store password as well. The store
password allows you to access and list the keys within the .p12 file from outside of BlueSeer as
necessary. For example, the JDK / JRE offers a command to manipulate and list .p12 store files. The
command is keytool, and an example of it's usage is provided below.
c:\bs\blueseer\jre17\bin\keytool -list -v -keystore test2.p12 -storetype PKCS12
To enter a new store, click the new button and enter an arbitrary name for your new key store. Then
enter a description and a directory/filename into the File text-box to store the .p12 file. You can enter
a path relative to the parent BlueSeer directory as such (works for windows or linux) :
edi/certs/mysamplestore.p12
Once you have entered the filename, then enter a password for the store object. Click the add button
when finished which will commit the store type record.
15.12 FTP and SFTP Maintenance (navcode: ftp)
BlueSeer provides an FTP and sFTP client option. Both protocols are supported with the FTP
Maintenance menu. You can navigate to the FTP Maintenance menu using navcode value of "ftp".
The FTP maintenance menu is shown in figure 14.12.1. To create a new FTP client record, click the
new button and enter a representative value in the code field. This code value is arbitrary and can be
any value that best represents the FTP client connection you are creating. There is a checkbox marked
'sftp' under the main tab. If this field is checked, the record will be created using the sftp protocol,
otherwise, an uncheck sftp box will establish a record for the plain ftp protocol. If you want to use the
plain FTP protocol, leave the sftp checkbox unchecked. Note that checking the sFTP check-box will
automatically assign the port to '22'. The enabled checkbox is used by background jobs
(Cron/Scheduled jobs) that call the FTP record. If the enabled checkbox is unchecked, background
jobs that attempt to execute this FTP client record will be suppressed. This is a convenient way to
disable the specific ftp client from running during execution if you need to pause or stop it's execution
occurrence. The remaining fields are explained below in section 14.12.1.

15.12.1 FTP Maintenance Field Definitions

This is a list of various vendor maintenance related fields that warrant further description :
• Code (text-box) This field is a table key field. It is used to represent the specific ftp client
record you are establishing. The value is arbitrary but mandatory.
• Enabled (check-box) This field enables or disables this specific FTP client record from being
seen/executed by background jobs.
• sFTP (check-box) The sftp checkbox field establishes the record as using the sFTP protocol. If
left unchecked, only standard FTP protocol will be used. If this box is checked, the intial value
of the port field is set to 22.
• Description (text-box) This field is an arbitrary description of the FTP record being
established.
• IP (text-box) This field assigns the IP address of the target ftp (or sftp) host server. URL
addresses can be used as well.
• Port (text-box) This field assigns the Port number to be used for ftp or sftp. In the case of sftp,
this value is usually '22'. It can be left blank for plain FTP unless the host server specifies
different.
• Login (text-box) This field is used to store the username of the ftp or sftp client session. The
username is typically provided by the host ftp server owner.
• password (text-box) This field is used to store the password of the ftp or sftp client session.
The username is typically provided by the host ftp server owner. The password is encrypted
when stored in the database, and decrypted upon retrieval.
• In Directory (text-box) This field represents the local directory where you will store files with
the execution of the 'get' command.
 • Out Directory (text-box) This field represents the local directory where you will retrieve files
with the execution of the 'put' command.
• Commands (text-area) This text-area box contains a list of commands that can be used once
the connection has been established. Any valid command can be used as long as they are
separated by new-line characters. An example is provided below.

• Delete (check-box) this checkbox will delete files after using the 'get' command. There is no
need to manually include a 'delete' command if this check-box is checked.
• Passive (check-box) If the passive check-box is checked, the ftp protocol will set the transport
mode to 'passive'. This is not applicable to sftp.
• Binary (check-box) If the binary check-box is checked, the ftp protocol will set the file transfer
type to binary (as opposed to ascii).

15.12.2 sFTP authentication

sFTP can use either password or private key authentication. Private Key is typically used for better
security and requires the existence of four keys (two sets of public/private key pairs) :
• Client Public Key
• Client Private Key
• Server Public Key
• Server Private Key
The client's public and private keys are used to authenticate the client to the server when using the
SFTP protocol. The client private key is typically stored as a file (/home/user/.ssh/id_rsa) and the client
public key is typically stored in the same folder as /home/user/.ssh/id_rsa.pub . The client's public key
must be provided to the owner of the host server and registered on the server. The server's public key
can be issued to each client as a means to validate the server that the client is connecting to. The use of
the server's public key is optional if the attribute StrictHostKeyChecking is set to no.
Note: The client and server private keys are used by the respective local system and are not to be
shared or exchanged.
BlueSeer can use either password authentication or private key authentication for sftp
authentication. If the usePrivateKey attribute value is set to no, then the system will assume the client
connection is using password authentication only. If it is set to 'yes', then the privateKeyPath attribute
must be set as well in order to use private key authentication. The key/value pairing of attributes are
provided below.
Attributes Table (case sensitive keys and values)
Key Value
usePrivateKey yes or no
privateKeyPath path to private key file ex: /home/user/.ssh/id_rsa
knownHostsPath Path to known host file ex:
/home/user/.ssh/known_hosts
StrictHostKeyChecking yes or no
PreferredAuthentications publickey,password,keyboard-interactive
Figure 15.12.1
15.13 Utility Services (run server classes as a Windows Service)
There are several BlueSeer java sever level classes that can be run as service jobs in the background.
On the Windows OS, these server classes can be executed as a Windows Service with the help of the
Apache Commons Daemon library. The Apache Commons library is a separate library from BlueSeer
and will need to be downloaded. You can download the library at the following URL:
https://dlcdn.apache.org/commons/daemon/binaries/windows/
Note: both 32bit and 64bit executables of prunsrv.exe are provided within the zip file, however, the
64bit resides under the amd64 subdirectory in the download. Once it is installed, you can choose to
adjust your PATH environment variable to include the absolute path to the prunsrv.exe or you can just
call the absolute path in the command below. Here's an example of running the BlueSeer cronServer
daemon as a Windows Service :
Open a powershell window and cd to the executable directory where amd64\prunsrv.exe is
located.
Then type the below command:
Note: leave the back-ticks in place for easier cut and paste into powershell or remove the back-
ticks and enter as one complete command. Back-ticks are command line continuation in
powershell. Replace backticks with backslash if using DOS command prompt.
./prunsrv //IS//bscronServer --DisplayName="bscronServer" --Description="bscronServer" `
--Install="C:\apache\commons\amd64\prunsrv.exe" `
--Jvm="C:\blueseer\jre17\bin\server\jvm.dll" --StartPath="c:\blueseer" `
--StartClass="utilities.cronServer" --StartMode=jvm --StopMode=jvm `
--StopClass="java.lang.System" --StopMethod="exit" --StopParams=1 --Startup=auto* `
--Classpath="C:\blueseer\dist\*" --LogLevel=Info --LogPath="c:\blueseer\logs" `
--LogPrefix=procrun.log --StdOutput="c:\blueseer\logs\stdout.log" `
--StdError="c:\blueseer\logs\stderr.log"
If you type services.msc at the prompt, you should see the services dialogue window appear. A
service named 'bscronServer' should be visible in the list. Highlight the service and click 'start' to run
the service in the background. To stop the service, highlight the service entry and click 'stop'. Note: If
the service does not or cannot be stopped, you can open another powershell prompt and search for a
process running 'prunsrv.exe'. Find the process id (PID) associated with this executable. Then kill the
process with the taskkill command as shown below. This should stop the service.
To list the processes running type: tasklist |more
To kill the process type: taskkill /PID number /F
To delete the service entirely type: ./prunsrv //DS//bscronServer
The following BlueSeer classes (in above parameter --StartClass) can be executed as Windows
Services :
• utilities.apiServer (required for api and as2 server communication)
• utilities.cronServer (required for Cron/Scheduling job services)
16 API (BlueSeer)
BlueSeer has the capacity for client side calling of 3rd party APIs (discussed in 15.1) as well as
hosting internal service APIs within BlueSeer to allow other applications to create/update data within
the BlueSeer database (discussed in 15.2). The client side calling API is provided in the API
Maintenance Menu (navcode: apim). This menu maintains records of various api endpoints and
methods to call 3rd party APIs and either retrieve data are post data to these external service APIs.
The BlueSeer internal service APIs allow for the exchange of data between BlueSeer and other
peripheral application systems that may require some level of integration with the parent package. It
uses a simple java servlet architecture to provide the services for the APIs. BlueSeer utilizes the open
source embedded web server Jetty, developed by the Eclipse Foundation, to serve java servlets that
process HTTP requests and responses through the API interfaces. These APIs can be used in machine
to machine communication to retrieve and post various data in JSON format from various modules
with the BlueSeer application.

16.1 External API Clients

16.1.1 API Maintenance Menu (navcode: apim)

The API Maintenance menu can be used to create client side methods for calling 3rd party API
endpoints to either collection information or post information to external API services. An example of
an API record is shown in figure 15.1.1 with the detail tab being shown in figure 15.1.2. This example
is a client side api call to https://ipinfo.io and provides geographical information for a specific IP
address. This external API service does not require any authentication or API key and is free to use.
There are several API records provided in this menu that can be used freely and demonstrate the
behaviour of the calling api methods. The return values of these API calls are typically JSON
formatted strings.
The default installation comes with several standard APIs that do not require authentication or API
keys. For each API record, there can be multiple 'methods' for the same api endpoint. Clicking on
any given method assigned in the detail 'table' will highlight that specific method for update and
execution. If a table method is highlighted, you can click 'run' and the api client will execute the call
to the service API endpoint. If a value is returned, it will display in the text area. You can also save
the return content to a file by checking the file checkbox. The file will be placed in the standard
edi/api/in directory.
Figure 16.1.1
Figure 16.1.2

16.1.2 API Log (navcode: apil)

The API Log menu provides a browse option of all API call events to 3rd party API services. These
events are typically governed by cron entry records and scheduled per the cron settings.

16.2 Internal API Services

16.2.1 Host Application Service (Jetty)

The API Maintenance menu can be used to create client side methods for calli
There are many manufacturing scenarios where internal service APIs are useful. Many shop floor
functions are performed at production work stations. These work stations may have applications
developed specific to their function in other programming languages that could integrate BlueSeer APIs
for the purpose of programmatically sharing/exchanging information between the work station and the
BlueSeer ERP. Retrieving item master info, sales order info, or posting production directly from the
work station into BlueSeer are but a few examples where these APIs are useful.
As mentioned previously, BlueSeer uses the Jetty embedded web server to host the java servlets for
the API services. The server is initiated from the apiServer class within the BlueSeer utilities package.
The apiServer class is a simple class with a main method that instantiates the server. The server uses a
context path of /bsapi/ and port '8088' to serve content and respond to HTTP GET and POST requests.
The server is easily started from the command line as the following example shows:
Note: you should be in the BlueSeer parent directory when running the below java command.
 Prompt> java -cp “.;dist\*” utilities.apiServer

If the execution is successful, you will get output ending with something similar to :

This execution must be left running for as long as the API services are required. On linux, you can run
in the background if you wish. On Windows, it is advisable to set this execution as a Windows
Service.
To test the api server, you can enter the below in a browser from the box executing the above service
and you should see the following results :

Note: You will need to change 'localhost' to the name of the server actually running apiServer if you
are using a browser on a different box or work station.

16.2.2 Available API Services (Internal)

BlueSeer's APIs are limited to data exchange with the following Modules :

5) Sales Orders (Post and Get)

6) Work Orders (Post and Get)
7) Shipping (Post and Get)
8) Item Master (Get Only)
9) Customer Master (Get Only)

16.2.3 Sales Order API

The Sales Order API provides the ability to create sales orders from a third party application using
the api as well as retrieve information about a specific sales order. The API also provides the ability to
retrieve a list of orders with a few selection filters in the Parameters String of the 'GET' HTTP method.
The 'POST' HTTP method allows for the creation of a Sales Order if given an appropriate JSON object
within the post.
To retrieve a specific Sales Order, the API call would have to provide the id of the sales order. For
example, the following URL call would retrieve a JSON object for sales order '10001' :
http://servername:8088/bsapi/SalesOrder?id=10001

The response received would be a JSON object similar to the image below.

This (array) JSON object contains many fields associated with the Order as well as the detail lines in
an embedded array of JSON objects labeled 'Items'. Looping through the 'Items' tag will provide you
with a JSON object per item.

To retrieve a list of Sales Orders you can use the SalesOrderList path along with specific
parameters. You can enter something similar to the following URL :
http://servername:8088/bsapi/SalesOrderList?fromdate=2020-12-01&todate=2021-01-22

This will return an Array of JSON objects for each sales order within the range of the fromdate,
todate date range provided in the variables. The date provided will be the order date of the sales orders
in question. There are several other filtering variables that can be used. The list is below :
Variable Format Example
fromdate yyyy-mm-dd 2020-12-01
todate yyyy-mm-dd 2020-12-30
fromnbr integer 10001 (sales order number)
tonbr integer 19999 (sales order number)
fromcust varchar 20000 (customer number)
tocust varchar 29999 (customer number)
status Varchar open,closed,onhold

To create a Sales Order from a system outside of BlueSeer, you can use the API call to perform an
HTTP POST command to the /SalesOrder path. This must be a POST method HTTP call. A simple
example is shown below using 'Curl' to post an HTTP call to the URL. A JSON object with Status,
Message, and Key will be returned that indicates whether the transaction was successful. If successful,
the 'key' value will be the order number created in BlueSeer.
In order to create the sales order through the api call, a valid JSON object must be provided. In the
above example, a valid JSON object was created in file 'so_create.json' and passed to the HTTP POST
method. A valid JSON file example is shown below.
{"OrderNumber":"","Site":"1000","PONumber":"TestOrderX","OrderDate":"2021-01-
06","DueDate":"2021-01-06","Remarks":"test of
remarks","Type":"DISCRETE","Currency":"USD","ShipVia":"","Status":"open","BillToCode":"","Bill
ToName":"blah generic","BillToAddr1":"route
1","BillToCity":"Dillon","BillToState":"SC","BillToZip":"29536","ShipToCode":"","ShipToName":"so
me shipto name","ShipToAddr1":"BR549 Highway
SE","ShipToCity":"Dillon","ShipToState":"SC","ShipToZip":"29536","Items":
[{"ItemNumber":"50000001","Line":1,"UOM":"EA","CustItem":"","OrderQty":44,"ShippedQty":0,"Li
neStatus":"open","ListPrice":5,"NetPrice":5,"Discount":0,"LineLocation":"","LineWarehouse":""},
{"ItemNumber":"50000002","Line":2,"UOM":"EA","CustItem":"miscitem","OrderQty":444,"Shipped
Qty":0,"LineStatus":"open","ListPrice":2,"NetPrice":2,"Discount":0,"LineLocation":"","LineWarehous
e":""}]}

Note that the OrderNumber must be blank. Also, if a valid BillToCode and ShipToCode are passed in
the JSON object (for example...a returning customer) then no new address will be created. However, if
both BillToCode and ShiptoCode are blank, new address records in the Customer Master and ShipTo
Master will be created on the fly. Note further that if the ItemNumber that is passed in the JSON is not
an item already listed in the item master, then the item will still load on the order with a designation of
'miscellaneous' item.

16.2.4 Work Order API

The Work Order API is an interface specifically designed for posting production against a work
order from a client work station. The API does not create Work Orders, but instead, provides the
opportunity to report production of an item against a Work Order retrieved from the BlueSeer database.
The API allows for integration of a work station's specific programming with retrieval and reporting
operations performed by events at the work station. The API also provides the ability to retrieve a list
of work orders with a few selection filters in the Parameters String of the 'GET' HTTP method. The
'POST' HTTP method allows for the posting of production into inventory against a given Work Order
when given an appropriate JSON object within the post.
To retrieve a specific Work Order, the API call would have to provide the id of the work order. For
example, the following URL call would retrieve a JSON object for work order '100251' :
http://servername:8088/bsapi/WorkOrder?id=100251

The response received would be a JSON object similar to the image below.

The JSON object returned provides the work station with various fields associated with the work
order to support the function of creating the product, posting production, and controlling lot traceability
of the produced item.
To retrieve a list of Work Orders you can use the WorkOrderList path along with specific
parameters. You can enter something similar to the following URL :
http://servername:8088/bsapi/WorkOrderList?fromdate=2020-12-01&todate=2021-01-22

This will return an Array of JSON objects for each work order within the range of the fromdate,
todate date range provided in the variables. The date provided will be the scheduled date of the work
orders in question. There are several other filtering variables that can be used. The list is below :
Variable Format Example
fromdate yyyy-mm-dd 2020-12-01 (Scheduled Date)
todate yyyy-mm-dd 2020-12-30 (Scheduled Date)
fromitem varchar 50000001 (item number)
toitem varchar 59999999 (item number)
fromcell varchar CELL1 (cell label)
tocell varchar CELL9 (cell label)
status Varchar open,closed,void

To post production to inventory against a work order from a system outside of BlueSeer, you can use
the API call to perform an HTTP POST command to the /WorkOrder path. This must be a POST
method HTTP call. A simple example is shown below using 'Curl' to post an HTTP call to the URL. A
JSON object with Status, Message, and Key will be returned that indicates whether the transaction was
successful. If successful, the 'key' value will be the transaction ID of the posted production in
BlueSeer.

In order to create the work order through the api call, a valid JSON object must be provided. In the
above example, a valid JSON object was created in file 'wo_create.json' and passed to the HTTP POST
method. A valid JSON file example is shown below.
{"Action":"update","WorkOrderNumber":"100251","Item":"50000001","Site":"1000","Operation":"10
","QtyComplete":"50","DateComplete":"2020-01-
02","LotNumber":"12345","Operator":"Boo","PostComments":"well done"}

Note that the WorkOrderNumber must be the work order number being operated on at the work station.
Also, the “Action” code must have the value of “update”. You must also pass the specific operation of
the routing of the item that this specific work station is performing. In the above example, 50 pieces of
item 50000001 are produced at operation '10'. The lot number of '12345' is provided as traceability of
the production and can be used on subsequent prints and/or labels down stream.
16.2.5 Shipper API
The set of Shipper APIs within BlueSeer provides 3rd party applications the ability to communicate
shipping info between the application (a web application for example) and the BlueSeer ERP. A call to
the shipper list API can return a list of shippers given a set of parameters as filters. This list is returned
with various fields that describe aspects of each shipper. A call to a specific shipper, given a specific id
in a parameter field, will return a JSON object that has complete information about the specific shipper.
These 'retrieval' APIs are provided as HTTP 'GET' methods within the API and have associated
parameter names that provide filtering. The shipper API also allows for the programmatic creation of a
shipper document within BlueSeer. This specific API will consume a JSON object of shipper related
info via an HTTP 'POST' method call and create the shipper programmatically. The shipper ID is then
returned to the calling program.
To retrieve a specific Shipper, the API call would have to provide the id of the shipper as it exists in
the BlueSeer database. For example, the following URL call would retrieve a JSON object for shipper
id '2118' :
http://servername:8088/bsapi/Shipper?id=2118

The response received would be a JSON object similar to the image below.

The JSON object returned provides the calling program with various fields associated with the
shipper to be consumed as necessary (reports, email alerts, etc).
To retrieve a list of shippers you can use the ShipperList path along with specific parameters.
You can enter something similar to the following URL :
http://servername:8088/bsapi/ShipperList?fromdate=2020-12-01&todate=2021-01-22

This will return an Array of JSON objects for each shipper within the range of the fromdate, todate
date range provided in the variables. The date provided will be the effective ship date of the shippers in
question. There are several other filtering variables that can be used. The list is below :
Variable Format Example
fromdate yyyy-mm-dd 2020-12-01 (Scheduled Date)
todate yyyy-mm-dd 2020-12-30 (Scheduled Date)
fromnbr varchar 2000 (shipper id)
tonbr varchar 2999 (shipper id)
fromcust varchar 200001 (cust id label)
tocust varchar 299999 (cust id label)
status Varchar open,closed,void
 To create a shipper programmatically and post it to BlueSeer, you can use the API call to perform an
HTTP POST command to the /Shipper path. This must be a POST method HTTP call. A simple
example is shown below using 'Curl' to post an HTTP call to the URL. A JSON object with Status,
Message, and Key will be returned that indicates whether the transaction was successful. If successful,
the 'key' value will be the Shipper ID of the created shipper in BlueSeer.

In order to create the shipper through the API call, a valid JSON object must be provided. In the above
example, a valid JSON object was created in file 'sh_create.json' and passed to the HTTP POST
method. A valid JSON file example is shown below.
{"ShipperNumber":"","Site":"1000","OrderNumber":"","PONumber":"test po","OrderDate":"2021-01-
25","ShipDate":"2021-01-
25","Remarks":"","Type":"S","Currency":"USD","ShipVia":"PICKUP","Status":"1","BillToCode":"cas
h","ShipToCode":"cash","Items":[{"ItemNumber":"50000001","ItemDescription":"this test
item","Line":1,"Order":"10001","PO":"test
po","ShipQty":55,"UOM":"EA","CustItem":"","SkuItem":"","UpcItem":"","ListPrice":5,"NetPrice":5,"
Discount":0,"TaxAmt":0,"LineLocation":"","LineWarehouse":""}]}

Note that the ShipperNumber field must be blank. In the above example, 55 pieces of item 50000001
was shipped to bill-to code 'cash' and ship-to code 'cash'. Note: 'Cash' is a default code pre-installed in
BlueSeer during implementation. The bill-to code and ship-to code must already exist within BlueSeer
from a previously assign address for both bill-to and ship-to. Typically, this is the case when you're
shipping against an order that has been previously placed, and therefore the addresses have already
been assigned a code. Retrieval of these codes are accessed by accessing the OrderList API and the
specific Order id API that you are shipping against.
16.2.6 Customer API
The customer API allows for the retrieval of a specific Customer (bill-to) id or a range/list of
customers based on a set of provided parameters to the calling function. A call to the customer list API
can return a list of customers given a set of parameters as filters. This list is returned with various
fields that describe aspects of each customer. A call to a specific customer, given a specific id in a
parameter field, will return a JSON object that has complete information about the specific customer.
Note: the range/list API will return header information about the Customer master record for the range
of customers returned. However, the API that calls a specific customer ID will return not only
information about the customer (bill-to) but also a list of all ship-to codes associated with that customer
id. These 'retrieval' APIs are provided as HTTP 'GET' methods within the API and have associated
parameter names that provide filtering. There is no API that creates customer master records at this
time except for what is provided in the Sales Order creation API. You can create addresses on the fly
with the Sales Order creation API.
To retrieve a specific customer, the API call would have to provide the id of the customer as it exists
in the BlueSeer database. For example, the following URL call would retrieve a JSON object for
customer id 'cash' (NOTE: 'cash' is a pre-installed address for demonstration purposes):
http://servername:8088/bsapi/Customer?id=cash
The response received would be a JSON object similar to the image below.

The JSON object returned provides the calling program with various fields associated with the
customer as well as all ship-tos associated with that customer in an embedded JSON array with tag
“ShipTos”.
To retrieve a list of shippers you can use the CustomerList path along with specific parameters.
You can enter something similar to the following URL :
http://servername:8088/bsapi/CustomerList?fromnbr=00000000&tonbr=zzzzzzzz

This will return an Array of JSON objects for each shipper within the range of the fromnbr, tonbr
customer id range provided in the variables. The fromnbr and tonbr related to bill-to codes only (not
ship-to). There are several other filtering variables that can be used. The list is below :
Variable Format Example
fromnbr varchar 200001 (customer id)
tonbr varchar 299999 (customer id)
fromname varchar John Doe (customer name field)
toname varchar Zach Doe (customer name field)
fromzip Varchar Bill-to zip code
Tozip Varchar Bill-to zip code
16.2.7 Item API
The Item API allows for the retrieval of a specific items in the item master of BlueSeer as well as a
range of items based on calling parameters provided to the calling function. A call to the item list API
can return a list of items given a set of parameters as filters. This list is returned with various fields that
describe aspects of each item. A call to a specific item, given a specific id in a parameter field, will
return a JSON object that has complete information about the specific item. Note: the range/list API
will return header information about the item master record for the range of items returned. However,
the API that calls a specific item number will more detail related to the item master record. These
'retrieval' APIs are provided as HTTP 'GET' methods within the API and have associated parameter
names that provide filtering. There is no API that creates item master records at this time.
To retrieve a specific item, the API call would have to provide the specific item number as it exists in
the BlueSeer database. For example, the following URL call would retrieve a JSON object for item
number '50000001' :
http://servername:8088/bsapi/Item?id=50000001
The response received would be a JSON object similar to the image below.

The JSON object returned provides the calling program with various fields associated with the item
such as description, uom, selling price, purchase price, revision code, etc.
To retrieve a list of item numbers in a range you can use the ItemList path along with specific
parameters. You can enter something similar to the following URL :
http://servername:8088/bsapi/ItemList?fromitem=50000001&toitem=59999999

This will return an Array of JSON objects for each item within the range of the fromitem, toitem
item number range provided in the variables. There are several other filtering variables that can be
used. The list is below :
Variable Format Example
fromitem varchar 50000001 (item number)
toitem varchar 59999999 (item number)
fromcode varchar Item Code Type (M, P, A)
tocode varchar Item Code Type (M, P, A)
status Varchar Status (active, inactive)
Note for Item Code Type: M (manufactured), P (purchased, raw) , A (Assets)
17 EDI

EDI functionality is integrated within the BlueSeer application. Unlike other systems where the
EDI mechanics is typically a separate translation system, BlueSeer has built-in EDI functionality that
can act as a stand-alone EDI translator (document type to document type) or as a transformation engine
transforming X12 directly into the BlueSeer database tables (sales orders, acknowledgements) or in the
case of exported documents, directly from the database tables (invoices, ASNs, etc). Since every
trading partner's EDI mappings are unique, maps are a fundamental part of the process and specific to
the partner and document type engaged. BlueSeer supports the following map translations : X12, FF
(flat file), and CSV (comma delimited file). BlueSeer has a document recognition module that allows
for custom definition of flat file document structures as well as custom CSV files. The X12 file format
is auto-recognized by the processing engine per it's unique format.

17.1 Quick Guide Chronological Steps

1. The first step to setting up a new EDI document for your trading partner is to acquire the
implementation guide from your Trading Partner. If this is a vendor specific request, then you
would typically provide the implementation guide to your vendor. The implementation guide
defines the formats of the inbound and outbound documents to be exchanged.
2. Create the Trading Partner record in Trading Partner Maintenance (navcode= edtp) along with
any alias Ids that are relative to this specific trading partner.
3. Create the appropriate association record for this trading partner and document type in Partner
Transaction Maintenance (navcode= edpd) See detailed instructions below for Partner
Transaction Maintenance.
4. Create inbound and outbound structure files identifying the structure of the expected inbound
document format and the expected outbound document format. The structure files are stored in
edi/structure directory. Many pre-constructed structure files are available in the directory
during installation. These can be copied and manipulated as necessary. These files must be
registered in EDI File Structure Maintenance (navcode=mpsm) before a map can be
constructed.
5. Create appropriate map in Map Maintenance (navcode=map) for this specific document type
and compile it. Then select the name of the map in the appropriate record in Partner
Transaction Maintenance screen. The newly created map must be compiled before attempting
to load any EDI files with the EDI Load menu (navcode=edip) or with batch processing with
cron auto scheduling of batch load class. NOTE: the map creation process requires inbound
and outbound structure files to be created and registered before mapping. The EDI Structure
files are located in edi/structure and all have extention .csv. These files must be registered in
EDI File Structure Maintenance (navcode=mpsm) before a map can be constructed.

You can place a test/production file in the default 'edi\in' directory under the BlueSeer root directory
as defined in EDI Control Maintenance. The file should be visible in menu EDI Load menu
(navcode=edip). You can review the mapping results along with any errors using navcode 'edil' (EDI
Log browse).

17.2 Trading Partner Maintenance (navcode: edtp)

The trading partner id is typically the ID of the customer found in the header portion of the EDI
document whether the document be of type X12 or Flat-File (FF). If X12, the segment labeled “ISA”
is the EDI envelope segment and provides the sender / receiver identification numbers of the sender of
the document and receiver of the document. The GS segment provides another layer of sender /
receiver identification. Trading partner ids are typically in the ISA segment element 06 (senderid) and
ISA segment element 08 (receiverid), as well as the GS02 and GS03 respectively. Most of your trading
partners will provide you with an implementation guideline which details the trading partner ids used
along with a lot of useful detail regarding the transactions involved.
Once you've acquired your trading partner's ID, you will need to set it up in EDI Partner
Maintenance. See Figure 16.2.1 below. This menu allows for the assignment of a generic code to
represent the trading partner. You can assign various aliases or other identification numbers associated
with this trading partner as associated aliases to this parent code. The parent code will be visible on all
EDI log records for transactions associated with this trading partner. Any documents that use aliases
codes associated with this trading partner will return the parent code in the log views. This parent code
will also be the associative record ID associated the EDI Partner Transaction maintenance records.
This will tie the Trading partner parent code to all transactions defined for this specific trading partner
in EDI Partner Transaction Maintenance (edpd).
In Figure 16.2.1 below, the trading partner company, ACME Trading Co, has been assigned the
parent code 'ACME', and their ID, sent in the GS envelope, is '99999999'. This value has been
assigned as an alias to 'ACME'. There must be at least one alias defined, and at least one alias defined
as default.
Note: If dealing with X12 transactions, the default alias ID should always be the GS02 element.
BlueSeer views all EDI X12 transactions specifically at the GS level. You can enter the ISA sender id
as a secondary alias, but this may not be necessary as the ISA enveloping is dependent on the values in
the Partner Transaction Maintenance record (edpd) for each transaction type of a parent partner.
Figure 17.2.1
17.3 Partner Transaction Maintenance (navcode: edpd)

The primary purpose of Partner Transaction Maintenance is to allow the processing engine to
identify 1) which partner relationship the inbound source document belongs to, 2) which map to
execute against the inbound source document, and 3) assign variables identifying the final recipient of
the output destination document and associated variables to apply once the map has executed.
The Partner Transaction Maintenance menu is the administrative menu to manage the various
transactions (and their associated maps) for each trading partner. The Code field in the maintenance
screen contains the same value as the Code field in the Trading Partner Maintenance screen. This field
associates the trading partner with the various transaction types that the partner is requesting to
exchange. Examples of transactions are 850 (purchase order), 810 (invoice), etc. Each transaction that
will be communicated with your trading partner is defined here along with the corresponding map that
transforms from one format to another.
There are four primary keys for each record in this menu. There can also exist multiple records per
Code (key) field. The Code field is the main key. The other three fields (doc field, Recv GS field,
Sender GS field) along with the main key (Code) identify a unique record. Once these four keys are
assigned, you cannot change them. You would need to delete the record and add it back if one of the
four keys need changing. Other non-key fields can be updated as necessary for the unique record
identified by the four key fields.
It is important to note that the Record created in this menu is relative to the source file. Doc (key)
field indicates document type and is the document type of the source file being mapped. All (key)
fields are relative to the source inbound file. The only exception to this rule is that the additional
fields such as element, segment, etc, are all destination format specific and will be applied to the output
document being produced by the map.
The map class name is selected from the map drop-down box. The values in this map drop-down
box are retrieved from the list of maps that have been created/registered in Map Maintenance
(navcode=map). Note: the map class must be compiled in Map Maintenance before it can be used by
the processing engine. Maps are typically created and compiled within the edi/map directory, and this
directory is within the java classpath during application execution. Notice the selection of a specific
map in the drop-down selection box will also assign an ISF and OSF file association based on the map
meta data created during map creation in Map Maintenance. The ISF and OSF fields are also visible in
Figure 16.3.1 in their respective fields, however, these fields (and associated file type fields) are
disabled in this menu and can only be adjusted in Map Maintenance.
Figure 17.3.1a (primary tab)

Figure 17.3.2b (outbound options tab)

The following definitions represent the various fields in the Partner Transaction Maintenance menu :

• Code The code field represents the internal customer or vendor code as defined in EDI Partner
Maintenance. This field associates the master partner data with the partner transaction data.
• DocType This drop-down selection box represents the possible transaction / document types.
Choose the document type that the customer or vendor will be engaging. You can add or delete
from this drop-down box by adjusting the records in Generic Code Maintenance
(navcode=genm). The values are stored against the key 'edidoctype' as shown in the Generic
Code Browse (navcode=genb) menu as shown in Figure 16.3.2. These document type labels
have been arbitrarily chosen to reflect the type of document being processed at the source and
destination side. Examples are : 850, 850csv, 850idoc, ORDERS05, etc.
• Recv ISA This is the EDI envelope receiver ID in the ISA E08 field.
→ ISA*00* *00* *ZZ*ACME *ZZ*BLUESEER *120501*1553*U*00401*002273923*0*P*> Inbound

• Recv GS This is the GS level ID in the GS E03 field.

→ GS*PO*ACME*BLUESEER*20120501*1553*2273923*X*004010 Inbound

• Recv Q This is the Qualifier associated Receiver ISA. It is located in ISA El07. Typical
values are 12, 01, ZZ. It is always 2 characters in length.
→ ISA*00* *00* *ZZ*ACME *ZZ*BLUESEER *120501*1553*U*00401*002273923*0*P*> Inbound

• Map This field represents the custom map for this specific partner / document type
combination. The values in this drop-down field are created from Map Maintenance
(navcode=map).
• Sender ISA This is the EDI envelope sender ID in the ISA E06 field.
→ ISA*00* *00* *ZZ*ACME *ZZ*BLUESEER *120501*1553*U*00401*002273923*0*P*> Inbound

• Sender GS This is the GS level ID in the GS E02 field.

→ GS*PO*ACME*BLUESEER*20120501*1553*2273923*X*004010 Inbound

• Sender Q This is the Qualifier associated Receiver ISA. It is located in ISA El05. Typical
values are 12, 01, ZZ. It is always 2 characters in length.
→ ISA*00* *00* *ZZ*ACME *ZZ*BLUESEER *120501*1553*U*00401*002273923*0*P*> Inbound

• Elem Sep This field represents the element separator in the EDI document. All segments are
comprised of elemental fields. These fields are delimited by a separator. Typical separators are
ASCII code 42 which represents the asterisk character. The value of this field must be the
ASCII decimal code (integer format). This field is always 2 integers long.
• Seg Sep This field represents the segment separator in the EDI document. An EDI document
is comprised of segments. These segments are delimited by a separator. Typical separators are
ASCII code 10 which represents the new line character. The value of this field must be the
ASCII decimal code (integer format). This field is always 2 integers long.
• Sub Sep This field represents the sub-element separator in the EDI document. This field
represents the 16th element of the ISA segment. It is a single character and can be represented
by almost any character to further subdivide an element into an array of elments. Typical sub-
element separators are ASCII code 62 which represents the greater than character. The value of
 this field must be the ASCII decimal code (integer format). This field is always 2 integers long.
→ ISA*00* *00* *ZZ*ACME *ZZ*BLUESEER *120501*1553*U*00401*002273923*0*P*> Inbound

• Prefix This field is for outbound only. This assigns a prefix code of your choice to the
outbound document generated for this specific partner / document type combination.
• Suffix This field is for outbound only. This assigns a suffix code of your choice to the
outbound document generated for this specific partner / document type combination. Typical
values can be 'txt', 'edi'. The 'dot' will be placed automatically prior to the suffix.
• FilePath This field is for outbound only. This represents an alternate path (relative to the
blueseer root directory) for the outbound document.
• Version This field is for outbound only. This field establishes the EDI X12 version that will
be assigned in the ISA and GS segments.
• SupplierCode This field is for outbound only. A supplier code that is specific to this partner /
documentation type can be assigned here. This is typically your supplier code as assigned by
your customer and may or may not be different than your ISA ID.
• Outbound Document Type This field represents the type of document created on the
outbound side of the map. It represents the final product document type that the map will
create. The values are stored against the key 'edidoctype' as shown in the Generic Code Browse
(navcode=genb) menu as shown in Figure 16.3.2.
• Outbound File Type This field represents the type of file created on the outbound side of the
map. This field is governed by the map association as defined in Map Maintenance for the
map. Possible values are FF (flat-file), CSV (comma delimited), X12, UNE (Edifact), XML,
and JSON.
• ISF file This field represents the Inbound Structure File that defines the expected format of the
inbound document structure for the map. These structure files are defined in File Structure
Maintenance (navcode=mpsm).
• OSF file This field represents the Outbound Structure File that defines the expected format of
the outbound document structure for the map. These structure files are defined in File Structure
Maintenance (navcode=mpsm).
• Functional Acknowledgement This is a checkbox field that represents whether or not you
require functional acknowledgements (997) to be transmitted upon receipt of an inbound EDI
document. This is for Inbound only.
Figure 17.3.3
17.4 Structure File Maintenance (navcode: mpsm)

The Structure File Maintenance (SFM) menu provides a mechanism to define the format of a file
that will be operated on by a translation map. The structure file maintenance record defines both the
inbound format and outbound format that comprises the source and destination formats of any given
map. This menu defines the location of records and fields of a given format for recognition by the map
engine for data retrieval and data placement. Figure 16.4.1 below shows the user-interface for the
Structure File Maintenance menu. All files that will be operated on by a map must have a structure file
registered. Files types of x12, csv, xml, json, edifact, etc must be registered in the Structure File
Maintenance menu.
There are several key fields that define the meta-structure of a SFM record. Each structure is
defined by a document type and a file type. The document type is a drop-down list in the SFM menu.
The contents of the drop-down list are defined in Generalized Code Maintenance under the code
'edidoctype'. These are defined as the BlueSeer EDI document types. The document types use the
super set X12 nomenclature to identify the document. For example, an 810csv document type is an
invoice formatted in comma-delimited format. An 810xml is an invoice formatted in XML format.
Likewise an 810x12 is the standard invoice as defined by the x12 standards. There are six file types
supported within BlueSeer. The file types are: x12, csv, xml, json, ff (flat-file), une (EDIFACT).
The csv file type can be a delimited file using any delimiter. The version and description text-box
fields in the SFM menu are miscellaneous with the version field being arbitrary.
Figure 17.4.1
17.5 Document Recognition Maintenance (navcode: eddm)

The Document Recognition Maintenance menu provides records that define a specific document.
These documents are typically called flat-files (FF) and are represented usually by fixed length
segments/records in the document. These segment/records are defined by fields of fixed length. The
file that defines these types of documents reside in the edi/structure directory. These files can be
created and edited as necessary with any text editor. However, to provide the BlueSeer application
with a means of recognizing the file, the document structure maintenance record must be defined for
each Flat-file that will be encountered. This is done by providing rules in the Rules Recognition
Maintenance menu that help the application identify the type of flat file. There is usually a certain
field within specific records that are consistently provided within the file for each instance that can be
used for identification. Figure 16.4.1 below shows a Rules Recognition record, labeled as an 850idoc
that provides various rules to determine specific fields that identify this document as an IDOC of type
850 (ORDERS05).
To create a new Rules Recognition record, click 'new' and enter a code that best represents the
document in question. This code is used as a key for various lookup tables and will be the value
applied to 'DocType' in the EDI log entries on inbound and outbound transactions of Flat-File types.
The remaining header fields are defined as follows:
• Desc This is an arbitrary description field for informational purposes only.
• Type This value should be commensurate with the parent code and is typically the same value
as the parent code. This type field is a drop down selection box with values maintained in the
generalized code menu. You can add or delete these entries using navcode=genm. See
Generalized Code Maintenance for more info.
• SubType This is an arbitrary description field for informational purposes only.
• Segment Delimiter The segment delimiter for flat files is typically the newline (LF) character.
All values in this field must be the integer (decimal ascii) counterpart of the segment delimiter
character. In the case of the newline (LF) character, the integer value is 10.
• Element Delimiter The element delimiter is primarily used for CSV type files. If a CSV file is
being defined, assign the ASCII numerical value of 44 for the comma. Define as necessary for
other delimiters.
• Landmark The Landmark field is used to delineate the separation of unique documents of a
specific type with a file. This is used when there are multiple docs within a file. The
application will distinguish each unique document instance based on this value. The value is
typically the first unique identifier that represents the beginning (or next occurrence) of a
unique document instance.
• priority This field is a placeholder for future application use.

The rules definition records are a collection of rules for a specified document type that help the
application determine the document type during processing. The definitions of each field that
constructs the rule is provided below:

• Role This drop-down selection box has two possible values, (Selection, Data). The role field
dictates the purpose of the specific rule. If 'selection' is chosen, the rule is used by the engine as
 an identification rule to identify the document type. Rules marked as role-type 'selection' are
used to report back to the engine what type of file it has encountered. The 'data' type role is
only used once the document has been identified. It defines a specific piece of data in the file
that represents a tag variable. All rules marked as role-type 'data' must be accompanied with an
explicit tag. Currently available tags are (rcvid, sndid, doctype).
• RecordType The record type field specifies whether the rule can locate data at 'fixed' or 'regex'
record (row) locations within the file. If fixed, the row field must be specified and indicates to
the engine that this rule can be located at row x. If it is 'regex', a regex pattern is used to
determine which row (line) in the file contains the specified data point for this rule. 'regex'
record types are primarily used with 'data' role-type rules.
• ValueType The ValueType field has two possible values (constant and variable). If this field is
set as 'constant', then the value assigned to this 'tag' is hardcoded (constant). These are useful
when the selection rule has identified a document type, but the 'constant' value is not present in
the document, but merely implied. Constant type values are useful for associating tags with
values that may or may not be in the file and facilitate processing downstream.
• Row This is an integer field that represents the line, segment, or row within the document.
• Column This is an integer field that represents the starting position of the field (for value or
tag) that is under determination.
• Length This is an integer field that represents the field length (from starting position) of the
field (for value or tag) that is under determination. As an example, Figure 16.4.1 shows that the
location of the 'ORDERS05' value can be found within the 30 characters starting at column 40
on line (row) 1.
• Regex This textbox is only occupied with the RecordType is 'regex'. It indicates to the engine
that the row in the file to find the value is variable (inconsistent), and that the engine should
look for the first line (row) that contains the regex pattern match of the value in the regex field.
Once the line (row) is identified, then the column and length specify value of the tag in
question.
• Value This textbox is only occupied with the ValueType is 'constant'. It indicates to the engine
that regardless of what is in the document, this value should be assign to the corresponding tag.
Note that for ValueType = constant, the row,column, and length fields should be zero.
• Tag The tag field is used as global variables which are passed along to the engine for
processing the document. Currently available tags are (rcvid, sndid, doctype).
Figure 17.5.1
17.6 EDI Control File (navcode: edic)
The EDI Control menu provides a location to store relevant information about the EDI directory
environment. All the paths in the control fields are relative to the BlueSeer home folder location. For
example, you can create a directory called “your_in_directory/inbound” and place your inbound EDI
files within this directory. The loader program will look in the Default In Dir location for the inbound
files. In this case, the Default In Dir would be defined as “your_in_directory/inbound”...which should
reside within the BlueSeer execution folder. Figure 16.5.1 shows the screenshot of the default directory
values for the EDI environment. Notice there is an EDI folder within the BlueSeer directory. This EDI
directory has several sub-directories specifically for controlling the EDI traffic. The edi/batch
directory contains a snapshot of all inbound and outbound files processed by the engine. The IFS/OFS
directory contains the structure files that identify the document type that is being processed.
The archive check box dictates whether you desire to archive the processed documents
automatically. Leave this box unchecked if you already have other archiving methods in place. The
Delete checkbox will override the archive function by deleting the inbound file after processing.
The EDI control file maintains the identity of the System trade-id. The trade-id is the ISA and GS
Ids associated with the internal business. These two fields should be set with your business ISA and
GS sender/receiver values. There can be only one ISA/GS id per system. If the business has more
than one, you can apply the alterates as necessary within the individual maps for the specific
transactions, but one must be set as the default within the control file. The default values set are used
by the system for a variety of reasons with the primary duty of serving as lookup keys for identifying
outbound document maps for transactions exporting from the system i.e. 856, 810, etc. In this case,
the default values are used as keys to identify maps in Partner Transaction Maintenance where the
default ISA and GS are the registered sender Ids. Outbound maps are identified by Sender GS (from
the default GS ID in the control file), Receiver GS (from the EDI Xref Maintenance table), and
document type.
Figure 17.6.1
17.7 EDI Loader (navcode: edip)
To load EDI files, go to enter 'edip' in the navigation text-box on the main menu bar. This will bring
up a panel with a list of files that are sitting in the inbound queue. Note: The inbound queue is defined
in the EDI Control File. The first column of the file list has the actual file name within the queue. You
can click on this filename to show the contents of the file in the text area in the right panel. There is
also a 'load' toggle box in the second column of the list. Toggling this box on or off will select or de-
select files to be loaded. Any list items with the toggle box checked will load when you click the
'Process' button. After you've processed the files, you should go to the EDI Log menu to see the status
of the loaded files (pass/fail/audit information) (navcode = edil). Figure 16.6.1 shows the screen shot
of the EDI Loader program.
Figure 17.7.1
17.8 EDI Log Browse (navcode: edil)

The EDI Log menu is shown in Figure 26.7.1 below and is accessible from navigational code 'edil'.
The EDI Log menu allows you to audit edi inbound and outbound traffic and load. Various information
regarding the control numbers, dates, and trading partner Ids are visible within this reporting tool. You
can filter for specific transactions and/or specific trading partners with the options in the left panel.
You can also filter by load date as well. This log file essentially audits info type message as well as
error type messages, and you have the option to choose either or both in your output. The far right
panel allows you to view the raw file by clicking on the file name in column 5. With regards to
inbound orders (850), if the order successfully loaded, you will see the actual order number generated
in the Ref column. You can click on this column to navigate to the actual order in Order Maintenance.

Figure 17.8.1
17.9 EDI Mapping Mechanics

The EDI maps used by BlueSeer are simple java files maintained/created by the EDI Mapper tool
within the application. There are many formats of EDI, however, BlueSeer only supports ANSI X12
and Flat File EDI formatting. The Flat file structure can be any structure as long as it is defined in
Document Recognition Maintenance and a structure file registered in Structure File Maintenance. All
structure files are maintained in edi/structures directory and are formatted according to comma-
delimited rules.
The X12 transaction set is governed by a specification provided by the x12 org committee. The
actual X12 specs can be purchased from the x12 organization, however, you can construct the
necessary structure file from the contents of your trading partners implementation guide (IG). The IG
typically follows the x12 specs, but can deviate from them as well, so it is best to construct your
Structure file from the trading partner's IG. The most prevalent x12 transactions in the ERP use case is
the purchase order (850), Ship Notice (856), and Invoice (810). Generic structure files (located in
edi/structures directory) have been created for these from various Implementation Guides. There are
generic sample maps for the EDI 850, 856, and 810 transactions. They are located in the edi/maps
directory. These maps are functional as-is for simulated sample data files provided during the install,
and these maps cover much of the typical usage of these transactions. If a custom map is required, it is
suggested to copy and rename one of the generic sample maps into the edi/maps directory. These maps
already have the necessary meta-data and structure files defined. The creation and or editing of maps is
discussed in the following section.
17.9.1 Mapper Tool (navcode: map)

BlueSeer comes with an EDI mapping tool to translate a document from a specific format to
another. The mapper is located under the EDI Main Menu. You can navigate to the mapper tool by
typing 'map' in the navigation text box on the main menu bar. The mapping tool is similar to an IDE
(Integrated Development Environment) in form and functionality. The mapper tool is shown below in
figure 16.8.1 with sample a sample map and input and output documents.
Figure 17.9.1

The toolbar menu has various icons that perform specific functions for the mapping tool. A list of
each icon is provided below with a brief description of functionality.

The "new" icon is the starting point for creating a new map. Clicking on this icon will reset all
input fields to their default values and set the input, output, and map panel to blank. You can
then enter a unique map name and source location for the map. Note: the source location
should be edi/maps/yourfilename.java including the .java suffix. Once you have all the input
fields assigned, click the "add map" icon which will save the map meta data to the map_mstr
table and create an empty file in the source path that you indicated.
The "find" icon allows the user to retrieve previously stored maps for editing and testing.
Clicking this icon will open a dialogue box where you can enter a search criteria to find a
specific map or you can just press <enter> and all maps will displayed in the dialogue browse.
Click the flag icon beside the specific map you desire and the contents of the map will be
displayed in the Map Panel along with the associated meta data of this map (in structure format,
out structure format, etc).
The "inspect" icon allows the user to view the contents of a structured raw file with an overlay
of the structure definition file. Clicking on this icon will display on the input panel and the IFS
structure format to review. Once you click the inspect icon, choose the IFS structure that best
fits the raw data file you wish to inspect and then right click in the Input Panel and choose
'overlay'. This will prompt for a source file (raw data file). Choose the raw file you wish to
review and click open. The raw file will be opened and the contents will be matched with the
segments and elements of the IFS structure file. Note: the structure file can be either inbound
or outbound as both directional structure files are assigned in IFS and OFS. As an example,
choosing IFS structure file X12850.csv will allow you to review the assignment and field names
of an 850 file against the structure definition.
The "clear" icon is clears all panels and fields and initializes the input fields back to their
default values.
The "add " icon is used in conjunction with the "new map" icon when creating a new map.
Once you have assigned all input fields associated with your new map, and added any initial
code to the map, clicking on the add map icon will create the new map to the source path
directory (unless a map file is already in the path...i.e. Copied from another map) and commit
all meta data associated with this map to the map_mstr table.
The "delete" icon is will delete the map_mstr record and all meta data associated with this
specific map and will then remove the java map file from the source path directory.
The "save" icon will save any adjustments to a previously created map record and map file.
This includes the meta data associated with the map as well as the contents of the file. Click
this icon as often as necessary to save any new code additions or changes to the map. Note: if
you change any meta data (for example the IFS or OFS) that is incommensurate with the
contents of the map file itself, there is no warning or preventive safeguards from doing so.
Make sure the meta data is commensurate with the map that you are writing/editing.
The "compile" icon will compile the map (java file) to a java jar file for usage in the translation
process. You must compile each map in order to test execution of the map in either the mapper
or by the translation engine. The maps must be compiled prior to usage. If there are any
compile errors, they will be displayed in the Output Panel. The errors will contain a line
number and an indicator of the problem. If there are no errors, a message indicating
compilation success will be displayed.
The "unhide" icon will display (re-display) all three Panels (Input, Map, Output). Each
individual Panel can be hidden to make room for the other panels by right clicking within the
panel and click 'hide'.
The "execute" icon will execute the map in the Map Panel (assuming it has been compiled)
against any content in the Input Panel. If there is no content in the Input Panel an error will be
displayed in the Output Panel. Note: the map must be compiled before executing. An error
will be displayed in the Output Panel otherwise indicating Class cannot be found.
The "leftshift" icon will hide the Input Panel and leave the Map and Output Panels in view.
This is used to provide more room for visibility. To display all panels, click the unhide icon.
The "rightshift" icon will hide the Output Panel and leave the Map and Input Panels in view.
This is used to provide more room for visibility. To display all panels, click the unhide icon.
 The following input fields in the Mapper tool are discussed below :
• Map: This is the map id field and is used as the primary unique name for the map
• Source: This field is the source path of the actual map file (java file). This is
typically assigned as edi/maps/somemapname.java
• Desc: This field is optional and used as a descriptive reference to the map
• IFS: This drop-down is a list of all inbound file structure types currently defined.
These are maintained in Structure File Maintenance.
• OFS: This drop-down is a list of all outbound file structure types currently defined.
These are maintained in Structure File Maintenance.
• InDocType: This is a listing of all document types supported by the current application
version. These are defined in Generalized Code Maintenance. All 'db' related
doc types are specific to BlueSeer database i/o.
• OutDocType: This is a listing of all document types supported by the current application
version. These are defined in Generalized Code Maintenance. All 'db' related
doc types are specific to BlueSeer database i/o.
• In File Type: This is a listing of the File types supported (FF, X12, DB)...FF=FlatFile. FF
types are any flat file type as defined in Document Recognition Maintenance
• Out File Type: This is a listing of the File types supported (FF, X12, DB)...FF=FlatFile. FF
types are any flat file type as defined in Document Recognition Maintenance
• Version: Optional descriptive only
• Package: Optional descriptive only

17.9.2 Mapping Process

The mapping process requires the construction of a single java class as a map. The java class is
constructed with the Mapper Menu and cannot be constructed outside the mapper due to customized
java statements prefixed to the class during the compile process. The contents of the map must
conform to certain method and variable usage consistent throughout all inbound and/or outbound maps.
The mapper class accommodates per-defined methods to use within the map. A listing of these per-
defined methods can be obtained by right clicking in the map area and clicking "List Methods". A list
of methods will be displayed in the Output Panel. The list will contain each method, the return type,
and parameters to the method. A short description is provided as well.
A standard map can be classified in two different categories depending on whether the map is
intended for format-to-format transformation or format-to-db (or db-to-format) usage. The latter types
are intended for maps that either load data into the BlueSeer database or create files from the BlueSeer
database. The format-to-format usage is typically used when the application is used as a stand-alone
EDI translator ...ire. consuming files of one format and creating files of a different format.
 Maps that are considered of type format-to-format will require a source data feed (referred to as
source data) and an output feed (referred to as destination data) into a designated output file. The map
class itself houses only the transformation logic, and relies on input document recognition logic in the
loader program (translation engine) to determine which map to fire. When testing in the mapper, the
input file you choose to test with should be commensurate with the map IFS value you are using.
Figure 16.8.2 shows an example of a X12 850 to IDOC transformation map. The sample java file
(bs850toIDOC.java) is in the edi/maps default directory. The map file is essentially a java file, and it
must conform to java rules during compilation. One of the strengths of the mapper tool is that any
java statement, syntax can be used within the map as long as it conforms to appropriate java syntax and
accepted by the compiler. Third party libraries can be imported using the java 'import' statement as
well. Java String methods such as substring(), length(), contains(), etc can be used within the map as
necessary. You can use any java syntax as defined up to and including Java Version 17.
Most of the map 'code' is specific to creating destination segments from input segments of source
data or from constants/variables declared as necessary within the map). Note: the mapping process
itself is best viewed as a top-down effort in constructing the desired content. The primary method used
to assign content (destination) data is the mapSegment() method. The method is used repeatedly
throughout the map and is the primary construct in creating output content. This method takes 3 String
parameters. The first parameter is the destination segment tag as defined in the OSF (outbound
structure file) for the destination format. A segment can be considered as a 'row' of data comprised of
'fields/elements'. The second parameter is the specific field/element of that segment. And, the third
parameter is the value to be placed in the field. The value can either be a constant or a returned value
from any one of the getInput methods. The getInput method(s) are the second most used method
within the map. These getInput 'overloaded' methods are designed to retrieve specific data fields from
specific segments within the source data file. The mapSegment assignment below assigns an IDOC
segment “EDI_DC” and field “idoctyp” with the constant value of “ORDERS05”. The subsequent
example shows the mapping of the “belnr” field in the appropriate segment with data from the inbound
EDI 850 BEG segment / element 3.
mapSegment("EDI_DC","idoctyp","ORDERS05");
mapSegment("E2EDK01","belnr",getInput("BEG",3));
Once all the fields of a particular segment has been assigned, the commitSegment() method is called
to commit the segment to the destination data object. The below example shows portions of an 856 to
850 transformation where an ASN is used to create a Sales Order and the BSN shipper ID in element 2
is used as the purchase order in the BEG segment 3.
mapSegment("BEG","e01","00");
mapSegment("BEG","e02","NE");
mapSegment("BEG","e03",getInput("BSN",2));
commitSegment("BEG");
Notice that the getInput method can take a variety of different parameter types getInput(String,
Integer), getInput(String, String), getInput(Integer, String, String) etc. For more detail on the getInput
overloaded methods, rightclick within the map panel and choose "List Methods". All possible
overloads of the getInput method will be displayed along with usage examples.
This pattern of mapSegment followed by commitSegment is continued until all proposed output
segment/fields have been assigned to the destination object and represents the bulk of the actual map
content.
The setReference() method is of special note and is used to set a reference key in the EDI log browse to
identify the specific transaction being processed. This is typically the PO number for 850s, or Shipper
number for ASNs. Only one reference can be set per transaction. This is optional usage.
setReference(getInput("BEG",3)); //optional...but must be ran after mappedInput

Once the map has been constructed and compiled, it is placed in the classpath directory where the
BlueSeer application can see it. By default, it looks in the edi/maps directory. Any maps compiled in
the Mapper menu will be automatically placed as jar files within the edi/maps directory. Note: this
needs to be done before you attempt to use the map in either testing mode or in production mode by the
translation engine.

Figure 17.9.2
bs850toIDOC.java

setReference(getInput("BEG",3)); //optional...

//optional...set some global variables as necessary

var now = now();
var mandt = "110";
var docnum = padNumber(c[4],16);
var segnum = 0;
var psgnum = 0;
var hlevel = 0;

// begin mapping

mapSegment("EDI_DC","tabnam","40_U");
mapSegment("EDI_DC","mandt",mandt);
mapSegment("EDI_DC","docnum",docnum);
mapSegment("EDI_DC","mestyp","ORDERS");
mapSegment("EDI_DC","sndpor","SAPPEN");
mapSegment("EDI_DC","sndprt","LS");
mapSegment("EDI_DC","sndprn","ACME");
mapSegment("EDI_DC","idoctyp","ORDERS05");
mapSegment("EDI_DC","rcvpor","EDI");
mapSegment("EDI_DC","rcvprt","LI");
mapSegment("EDI_DC","rcvpfc","LF");
mapSegment("EDI_DC","credat",now.substring(0,8));
mapSegment("EDI_DC","cretim",now.substring(8,14));
commitSegment("EDI_DC");

segnum++;
hlevel++;
mapSegment("E2EDK01","mandt",mandt);
mapSegment("E2EDK01","docnum",docnum);
mapSegment("EDEDK01", "segnum", padNumber(segnum,6));
mapSegment("EDEDK01", "psgnum", padNumber(psgnum,6));
mapSegment("EDEDK01", "hlevel", padNumber(hlevel,2));
mapSegment("E2EDK01","curcy","USD");
mapSegment("E2EDK01","hwaer","USD");
mapSegment("E2EDK01","wkurs",getInput("N1","1:ST",4));
mapSegment("E2EDK01","belnr",getInput("BEG",3));
commitSegment("E2EDK01");

// E2EDK14 loop
var addrloop = getLoopKeys("N1");
for (var key : addrloop) {
segnum++;
hlevel++;
mapSegment("E2EDK14","mandt",mandt);
mapSegment("E2EDK14","docnum",docnum);
mapSegment("E2EDK14", "segnum", padNumber(segnum,6));
mapSegment("E2EDK14", "psgnum", padNumber(psgnum,6));
mapSegment("E2EDK14", "hlevel", padNumber(hlevel,2));
mapSegment("E2EDK14","qualf",getInput(key,1));
mapSegment("E2EDK14","orgid",getInput(key,4));
commitSegment("E2EDK14");
}

// DTM Loop
var dtmloop = getLoopKeys("DTM");
for (var key : dtmloop) {
segnum++;
hlevel++;
mapSegment("E2EDK03","mandt",mandt);
mapSegment("E2EDK03","docnum",docnum);
mapSegment("E2EDK03", "segnum", padNumber(segnum,6));
mapSegment("E2EDK03", "psgnum", padNumber(psgnum,6));
mapSegment("E2EDK03", "hlevel", padNumber(hlevel,2));
mapSegment("E2EDK03","iddat",getInput(key,1));
mapSegment("E2EDK03","datum",getInput(key,2));
commitSegment("E2EDK03");
}

// N1..N4 group loop for E2EDKA1 segments

var n1count = getGroupCount("N1");
for (var i = 1; i <= n1count; i++) {
segnum++;
hlevel++;
mapSegment("E2EDKA1","mandt",mandt);
mapSegment("E2EDKA1","docnum",docnum);
mapSegment("E2EDKA1", "segnum", padNumber(segnum,6));
mapSegment("E2EDKA1", "psgnum", padNumber(psgnum,6));
mapSegment("E2EDKA1", "hlevel", padNumber(hlevel,2));
mapSegment("E2EDKA1","parvw",getInput(i,"N1",1));
mapSegment("E2EDKA1","lifnr",getInput(i,"N1",4));
mapSegment("E2EDKA1","name1",getInput(i,"N1",2));
mapSegment("E2EDKA1","stras",getInput(i,"N1:N3",1));
mapSegment("E2EDKA1","stras2",getInput(i,"N1:N3",2));
mapSegment("E2EDKA1","ort01",getInput(i,"N1:N4",1));
mapSegment("E2EDKA1","regio",getInput(i,"N1:N4",2));
mapSegment("E2EDKA1","pstlz",getInput(i,"N1:N4",3));
mapSegment("E2EDKA1","isoal",getInput(i,"N1:N4",4));
commitSegment("E2EDKA1");
}

segnum++;
hlevel++;
mapSegment("E2EDK17","mandt",mandt);
mapSegment("E2EDK17","docnum",docnum);
mapSegment("E2EDK17", "segnum", padNumber(segnum,6));
mapSegment("E2EDK17", "psgnum", padNumber(psgnum,6));
mapSegment("E2EDK17", "hlevel", padNumber(hlevel,2));
mapSegment("E2EDK17","qualf","001");
mapSegment("E2EDK17","lkond","ZZ");
mapSegment("E2EDK17","lktxt",getInput("FOB",2));
commitSegment("E2EDK17");

// comments // E2EDKT1, E2EDKT2 (hard coded source)

segnum++;
hlevel++;
mapSegment("E2EDKT1","mandt",mandt);
mapSegment("E2EDKT1","docnum",docnum);
mapSegment("E2EDKT1", "segnum", padNumber(segnum,6));
mapSegment("E2EDKT1", "psgnum", padNumber(psgnum,6));
mapSegment("E2EDKT1", "hlevel", padNumber(hlevel,2));
mapSegment("E2EDKT1","tdid","0001");
mapSegment("E2EDKT1","tsspras_iso","EN");
commitSegment("E2EDKT1");

// MSG segments
var msgloop = getLoopKeys("MSG");
for (var key : msgloop) {
segnum++;
hlevel++;
mapSegment("E2EDKT2","mandt",mandt);
mapSegment("E2EDKT2","docnum",docnum);
mapSegment("E2EDKT2", "segnum", padNumber(segnum,6));
mapSegment("E2EDKT2", "psgnum", padNumber(psgnum,6));
mapSegment("E2EDKT2", "hlevel", padNumber(hlevel,2));
mapSegment("E2EDKT2","tdline",getInput(key,2));
commitSegment("E2EDKT2");
}

// line items PO1..PID group

var po1count = getGroupCount("PO1");
for (var i = 1; i <= po1count; i++) {
segnum++;
hlevel++;
mapSegment("E2EDP01","mandt",mandt);
mapSegment("E2EDP01","docnum",docnum);
mapSegment("E2EDP01", "segnum", padNumber(segnum,6));
mapSegment("E2EDP01", "psgnum", padNumber(segnum,6));
mapSegment("E2EDP01", "hlevel", padNumber(hlevel,2));
mapSegment("E2EDP01", "posex", padNumber(i,6));
mapSegment("E2EDP01","menge",getInput(i,"PO1",2));
mapSegment("E2EDP01","menee",getInput(i,"PO1",3));
mapSegment("E2EDP01","pmene","EA");
mapSegment("E2EDP01","vprei",getInput(i,"PO1",4));
mapSegment("E2EDP01","matnr",getInput(i,"PO1",7));
mapSegment("E2EDP01","matnr_external",getInput(i,"PO1",9));
commitSegment("E2EDP01");

segnum++;
hlevel++;
mapSegment("E2EDP02","mandt",mandt);
mapSegment("E2EDP02","docnum",docnum);
mapSegment("E2EDP02", "segnum", padNumber(segnum,6));
mapSegment("E2EDP02", "psgnum", padNumber(segnum,6));
mapSegment("E2EDP02", "hlevel", padNumber(hlevel,2));
mapSegment("E2EDP02", "qualf", "001");
mapSegment("E2EDP02","belnr",getInput(i,"PO1",7));
commitSegment("E2EDP02");

segnum++;
hlevel++;
mapSegment("E2EDP20","mandt",mandt);
mapSegment("E2EDP20","docnum",docnum);
mapSegment("E2EDP20", "segnum", padNumber(segnum,6));
mapSegment("E2EDP20", "psgnum", padNumber(segnum,6));
mapSegment("E2EDP20", "hlevel", padNumber(hlevel,2));
mapSegment("E2EDP20", "wmeng", getInput(i,"PO1",2));
commitSegment("E2EDP20");

segnum++;
hlevel++;
mapSegment("E2EDP19","mandt",mandt);
mapSegment("E2EDP19","docnum",docnum);
mapSegment("E2EDP19", "segnum", padNumber(segnum,6));
mapSegment("E2EDP19", "psgnum", padNumber(psgnum,6));
mapSegment("E2EDP19", "hlevel", padNumber(hlevel,2));
if (i == 0) {
mapSegment("E2EDP19", "qualf", "001");
mapSegment("E2EDP19", "idtnr", getInput(i,"PO1",7));
} else {
mapSegment("E2EDP19", "qualf", "002");
mapSegment("E2EDP19", "idtnr", getInput(i,"PO1",9));
}
mapSegment("E2EDP19", "ktext", getInput(i,"PO1:PID",5));
commitSegment("E2EDP19");
}

// end mapping
17.9.3 Mapping Methods

There are several methods that can be used to retrieve data from the source data object. Some of
these methods are specific to retrieving data in a loop construct. These methods are described below.

The getInput method can take either a string or an integer in the second parameter to identify the
specific field of the segment. As a string, it locates the field 'name' as defined in the OSF. As an
integer, it locates the positional value of that field within the segment as defined in the OSF.
getInput("BEG","e03"); // Returns a string value of the purchase order number in the 3 element of BEG

getInput("BEG",3); // The same...but using an integer to locate the 3 rd field in the BEG segment

A variant of the getInput method can take 3 parameters. This variant method identifies the specific
source data object that contains the matching field values of the 2nd parameter. For example, if there
are multiple N1 segments and the element 4 of the specific segment that has qualifier “ST” is required,
the below method will isolate this value and return as a string.
getInput("N1","1:ST", 4); // returns the 4th element of the N1 if qualifier is ST (in the 1 st element)

getInputISA(x) will return a string value of the specified element within the ISA.
getInputISA(6); // Returns the Sender ID of the ISA segment

getInputGS(x) will return a string value of the specified element within the ISA.
getInputGS(2); // Returns the GS Sender ID of the GS segment

segmentExists(x,y,z) The segmentExists method is used to determine whether or not a specific

segment and field of that segment exists anywhere in the source data object. This is useful if you want
to set a fallback value in case the segment/field does not exists. The following example shows an
if/else condition that looks for the existence of the 002 Due Date qualifier in the DTM segment.

if (segmentExists("DTM","1:002","e01")) {

value = getInput("DTM","1:002","e01");

} else {
value = LocalDateTime.now().format(DateTimeFormatter.ofPattern("yyyyMMdd"));
}
 getLoopCount(x) The getLoopCount method is used to determine the number of occurrences of a
specific segment that is repeating (looping). For example, the N1 segment in an EDI 850 document
could have more than one occurrence and possess child segments that will loop with the parent as a
group. The N3 and N4 segments are considered child segments of the N1 parent segment. These
segments will loop together as a group. The below snippet of code shows how to loop over a segment
group and acquire specific segments and child segment values. Child segments are obtained by
prefixing the parent segment in a chain like "N1:N3" or "PO1:PID:MEA" as an example of 3 levels
deep chaining.

int po1count = getLoopCount("PO1");

for (int i = 1; i <= po1count; i++) {

mapSegment("E2EDP01","matnr",getInput("PO1",7, i));

mapSegment("E2EDP01","menge",getInput("PO1",2, i));
commitSegment("E2EDP01");
mapSegment("E2EDP19","ktext",getInput("PO1:PID",5, i));
commitSegment("E2EDP19");
}

One of the great advantages of the mapping getInput methods is the ability to acquire a specific value
from a group/loop without actually having to be inside the loop. For example, if the value you desired
was always in the nth occurrence of segment X, you can perform a mapSegment assignment with the
getInput method where the 3rd parameter is the nth loop. This of course assumes the input file is
consistently sent in this manner. This ability distinguishes BlueSeer mapping from other mapping tools
by not requiring a destination 'indented' structure mirroring the source 'indented' structure.

Figure 17.9.3

Control Element Assignment Comments

c[0] senderid For inbound, this is the ISA 06
element; for outbound this is the
BlueSeer code for bill-to,
warehouse, or carrier code
c[1] doctype Document Type (850, 810, etc)
c[2] map The Package qualified map name;
for example
EDIMaps.Generic810o
c[3] infile Inbound file (inbound only)
c[4] ISA_controlnum ISA control number (inbound only)
c[5] GS_ctrlnum GS control number (inbound only)
c[6] ST_controlnum (docid) ST control number (inbound only)
c[7] ref Reports the key field created; for
example order number, shipper
number, etc (inbound only)
c[8] outfile Outbound file name
c[9] sd Segment Delimiter
c[10] ed Element Delimiter
c[11] ud Sub Element Delimiter
c[12] override Override (used at command line to
avoid DB read and translate format
to format directly)
c[13] ISA_String Entire String of ISA envelope
(inbound only)
c[14] GS_String Entire String of GS envelope
(inbound only)
c[15] direction Direction of document (1=inbound;
0=outbound)
c[16] idxnumber Log number of EDI log table entry
c[17] ISA_Start Starting character position of the
ISA string
c[18] ISA_End Ending character position of the
ISA string
c[19] ST_Start Starting character position of the
ST string
c[20] SE_End Ending character position of the SE
string
c[21] receiverid ISA receiver ID (inbound only)
c[22] comkey This element is edi_log key
c[23] return messg from map (status)
c[24] inbatch
c[25] outbatch
c[26] indir
c[27] outdir
c[28] infiletype ff, x12, xml, etc
c[29] outfiletype ff, x12, xml, etc
c[30] debug
c[31] outisastart
c[32] outisaend
c[33] outdocstart
c[34] outdocend
c[35] outsegdelim
c[36] outeledelim
c[37] outsubdelim
c[38] message
17.10 EDI Processing (Auto Schedule)

The typical processing of EDI files involves some level of automation. A scheduled operation is
usually constructed to execute the processing of the files as a background job. With BlueSeer,
automated setup is easy and can be established relatively quickly with one of two options discussed
below.

17.10.1 EDI Processing using the internal Cron Scheduler

EDI auto loading is typically performed in BlueSeer using the internal cron mechanism provided by
BlueSeer. This is the easiest option for auto loading EDI documents through the BlueSeer EDI Engine.
This requires the BlueSeer cron service to be running in the background. BlueSeer comes with a
standard EDI cron job that can be called at whatever frequency you wish the auto loading event to
occur.
To set up this auto-loading mechanism, you must first start the BlueSeer cron service running. This
is usually executed in the background on Linux or as a Service in Windows. The easiest way to launch
the service is to open up an additional linux bash shell (or windows command prompt) and type in the
following:
C:\> cd c:\blueseer
C:\> jre17\bin\java -cp "dist\*" utilities.cronServer

or on linux :
prompt$ cd /somedir/blueseer

prompt$ jre17/bin/java -cp "dist/*" utilities.cronServer

This will start the BlueSeer cron service within the shell. Leave the shell (or command prompt)
running. Or alternatively, run in the background with & for linux or create a Windows service for
Windows OS.
As the cron service runs it will print the results of execution to standard out within the shell or CMD
prompt. There is a watchdog job that checks every 1 min for any changes to cron jobs that the cron
service needs to act upon.
The cron Maintenance Menu in BlueSeer has a single default cron job called 'edi' that is created
during the installation. This job comes disabled by default. To start this job, type in 'cron' in the
Navigation Text-box on the menu panel and pull up the 'edi' job record. Click the enabled check-box
to enable the job. The cron service running in the background will see the newly enabled job and
execute the EDI loading on it's next scheduled run. By default, the edi cron job is scheduled to run
every 30 minutes. Once this job is enabled AND the cron service is running, the system will auto-load
documents in the default inbound directory (edi/in) through the EDI processor. By default, these files
will be removed from the default inbound directory to the archive directory. Any transactions loaded
will be visible in the edi log browse menu (navcode = edil). To disable auto-loading, uncheck the
enabled checkbox for the edi cron job record in Cron Maintenance.
 17.10.2 EDI Processing using OS native or 3rd party cron/schedulers
If you choose to use the Operating System (OS) native scheduler tools, you can use the EDILoad
class to auto load EDI documents. This is useful when scheduling batch processing at the OS level
using such as the Windows Task Scheduler or Linux Cron scheduler. Typically, the EDILoad java class
is wrapped in a .bat file for Windows or a bash shell script for Linux. (either the OS scheduler, cron
scheduler, or some other scheduling tool) and bat or shell files to call the BlueSeer executables. The
java class com.blueseer.edi.EDILoad is specifically created for auto processing of EDI files in both
stand-alone translation use (file to file) and export of System generated documents such as ASNs,
Invoices, etc. The EDILoad class comes with two parameters (-i and -o). The -i is used for all file-to-
file translations (regardless of whether it is an inbound or outbound document), and it does not require
any parameters after the -i designation. The -o parameter is used for auto-exporting documents from
the BlueSeer database tables, and it does require a comma-separated list of docs to export. The
available list of document type codes to pass with the -o option is (810, 856, 850, 855), representing
(invoice, asn, vendor purchase order, and return order acknowledgement respectively). Figure 16.9.1
shows the execution of the EDILoad class from a powershell command line for the -o option. Any
exported document will be dropped into the EDI default outbound directory as defined in the EDI
Control Menu.
Figure 16.9.2 shows the -i option usage. The -i option should always be used when using
BlueSeer as a stand-alone EDI translator tool. When using the -i option, any document, regardless
of format, placed in the default EDI In directory, will be processed per the inbound format
identification and the appropriate mapping. All documents on the output side will be placed in the
default outbound directory per the EDI control menu.
For inbound documents that are mapped directly to BlueSeer tables (inbound customer order 850,
inbound vendor purchase order ASNs, Acknowledgments, etc), the -i option should be used. If the
map is constructed with the proper 'isDBWrite' method, then the documents will load against the
appropriate BlueSeer table.

Figure 17.10.1

Figure 17.10.2
17.11 EDI Work Flow Maintenance (navcode=wkfm)

Work Flow functionality was added in BlueSeer Version 6.5. Used in conjunction with the
embedded cron service functionality, the Work Flow mechanics offer the ability to execute basic tasks
at the systems level and outside the basic venue of the user interface. Tasks such as moving files from
one directory to another, or archiving old files in directories, or kicking off api calls at specific times
can be achieved with the work flow maintenance module along with a running instance of the cron
service. Each work flow record created can possess child tasks that execute sequentially. BlueSeer
offers several basic tasks that can be used and represent typical operations found in most use-case
scenarios. It is also possible to create work flows that call os level script jobs and executed on a
specific cron schedule as necessary.
To create a work flow record, go to the EDI main menu and click the Work Flow Maintenance sub
menu or enter 'wkfm' in the navigational text-box on the main menu bar. Click the new button and
enter an arbitrary id associated with this work flow. Note: this id is also used as an associative key in
the cron maintenance records, should a cron record be created to execute this work flow id. Enter a
description for the work flow and check the enabled check-box. In the Action Maintenance panel,
choose a standard task and click the 'plus' button. This will add the task to the list pane. Highlight the
newly added task in the list pane, and the available key/value actions will be displayed in the table
below. Each standard task has one or more key/value actions available. Click on a row identifying
the option's key/value pair and enter the value in the appropriate text box. Once you have adjusted the
value portion of the key/value pairs, click the 'Update Key/Value' button. This will commit the
key/value pairs to this instance of record, however, you must then click the 'Add' button below to
commit the entire work flow record to the database. The same routine is also important in updating
the work flow record. Each key/value change must be accompanied by a 'Update Key/Value' event as
well as an 'Add' or 'Update' button click event to completely add or update the work flow record.
If you have another standard task for a work flow, you choose more tasks in the drop down and add
to the List Pane. Highlight on the specific task to show the key/value pairs of that task. You can also
change the order of the standard tasks by using the up and down buttons to the right of the List Pane.
Figure 16.11.1 shows a sample work flow record for copying all files from one directory to another
with various key/value assignments.
Many of the key/value pairs of a work flow depend on the nature of the task and are specific to that
task that is highlighted in the List Pane. Note: all directory entries in the key/value pairs can be
entered as forward slash separators for both Windows and Linux. For example, a directory value of
C:/BlueSeer/edi/in can be entered with forward slashes...even for windows. You can choose to enter
the trailing forward slash or not, the application will add the trailing slash as necessary for directories.
The application will also make the appropriate OS forward or back slash assignments as well. Boolean
type key/value pairs can be entered as lower case yes/no or true/false, or 1/0, respectively. Key/value
pairs that are used as file filters can use typical globbing expressions. For example, to grab all files
within a directory, use "*" in the filter key/value entry. To grab all .txt suffix files, use "*.txt" in the
filter key/value entry.
Datetime time stamping in destination filenames is available only on the following operations :
FileCopy, FileMove, FileMatchMove. These three operations have the ability to expand destination
filenames to incorporate a timestamp within the filename. As an example, the following destination
filename is parsed for the appropriate formatted datetime value : myfile.%yyyyMMddHHmmss%.txt .
The datetime formatting is defined by the standard datetime formatting descriptors. These descriptor
tags are case-sensitive and must be surrounded with the % characters.
NOTE: when clicking on the standard task in the List Pane, make sure the table title changes for the
respective task you have highlighted. Sometimes the key/value list does not change for the appropriate
task even though the standard task is highlighted in the List Pane. Simply click again to make sure the
correct title and therefore key/value options are provided.
The standard tasks are described below along with their respective key/value options.
• FileCopy This operation will copy a specific file from one path to another. This option has
three parameters: source, destination, append. The absolute path of the source file and
destination file needs to be assigned. There is an 'append' option that will allow appending to
the destination file if the file already exists. Assign a 'yes' or 'true' to the key/value pair of the
append option if you want to append, otherwise the destination file will be overwritten. The
original source file is left in place. This operation has the option to expand datetime stamps
within the destination filename.
• FileMove This operation will move a specific file from one path to another. This option is
similar to the FileCopy option, but will move (rename) the file to the destination path and
remove the source path. There is an 'overwrite' option that will replace the destination file with
the current file if the destination file path already exists. Assigning 'yes' or 'true' will overwrite
the destination file path. If you assign 'no' or 'false' (or leave blank) to the overwrite option
AND the destination file already exists, then the move operation will not occur. This operation
has the option to expand datetime stamps within the destination filename.
• FileMatchMove This operation is similar to the FileMove operation, but uses a regex
matching filter to identify the source files to move. Any files in a specified source directory
that matches the 'filter' option will be moved to the destination directory. This option will move
(rename) the file to the destination path and remove the source path. There is an 'overwrite'
option that will replace the destination file with the current file if the destination file path
already exists. Assigning 'yes' or 'true' will overwrite the destination file path. If you assign
'no' or 'false' (or leave blank) to the overwrite option AND the destination file already exists,
then the move operation will not occur. This operation has the option to expand datetime
stamps within the destination filename.
• FileDelete This operation will delete the source path explicitly assigned in the 'source'
key/value option.
• FileCopyDir This operation takes 4 key/value parameters (source directory, filter, destination
directory, overwrite). This operation will copy all files in source directory that match the filter
rule to the destination directory. The filter option can have wildcard characters specific to the
selection criteria used. For example, assigning *.txt in the filter option will copy all files in the
source directory that end with a .txt extension to the destination directory. To copy all files,
assign a "*" to the filter key/value option. The overwrite option controls whether or not a copy
operation will occur if the destination file already exists. If overwrite is 'yes' or 'true' AND the
destination file path already exists, the the file will be copied overwriting the original
destination path. If overwrite is 'no', 'false', or blank, the copy operation will not occur if the
file already exists in the destination directory. Note: placing a trailing '/' on the source or
destination key/value pair is optional. Forward slashes are typically used for both windows and
linux operation systems.
• FileMoveDir This operation is similar to the FileCopyDir operation in that it takes 4 key/value
parameters (source directory, filter, destination directory, overwrite). The only difference is
 that the files matching the filter option are moved (renamed) from source directory to
destination directory. The overwrite option works exactly the same as in the FileCopyDir
operation.
• FileDeleteDir This operation delete all files in a source directory. The operation takes two
key/value pairs. The source directory and the 'days' option. All files in the source directory
will be deleted depending on the days option assigned. The 'days' option specifies the files that
will be deleted that are older than the number of days provided. For example, assigning a value
of '30' to the days option will commit the operation to deleting all files older than 30 days in the
source directory. A value of '0' will delete all files.
• FileMap This operation will submit the file path object through the EDI translation engine.
This operation has one key/value pair which is the source file. This operation only processes
the source file through a given map and relies on Document Recognition rules to determine
which partner/map object to apply. The operation does NOT remove the source file once the
operation is complete. This operation is normally used in conjunction with an APICall or an
individual file processing action. Most translation events should be processed using the normal
edi processing cron service 'edijob'.
• APICall This operation will call an api service identified by an API id and method. This
operation has 4 key/value options. The API id and API Method must be provided to this
operation. The destination option is provided to assign a file path object to accommodate the
return value of the api call which is typically a json object. The source option is provided as a
source file path object to post to the api call.
• X12DirFilter This operation is useful for processing / trafficking multiple type of X12 EDI
files within a given directory. It is a file movement operation. The operation is based on the
'content' of the file by opening the file and determining what type of X12 document is present.
It does not rely on a file naming convention. It is used primarily as a method for separating
document types into different directories to perform subsequent operations depending on the
type. For example, all files of type 850 (purchase orders) can be separated into distinct
directories and processed independently of the other EDI document types. It is useful for
separating EDI X12 documents that are to be processed via different operation other than
translation, or for separating inbound from outbound document types within the same directory.
A configuration file that contains the rules must be provided and is the key/value pair labeled
'tffile'. The tffile consists of comma-delimited records of 4 fields each. The first field is the
X12 document type...example (850). The second field is the X12 ISAE06 senderid of the
document which is the trading partner identifier. The third field is the destination directory (that
overrides the default destination directory). The final fourth field is the archive directory (that
overrides the default archive directory). The example below shows that the rule in line 1 will
move all 850s that are not specific to a trading partner to the C:/some/folder/ directory...
whereas line 2 will be specific to trading partner 'ACME' and move ACME 850s to
C:/some/other/folder/ .

850,,C:/some/folder/,
850,ACME,C:/some/other/folder/,
997,,C:/some/report/folder/,

The ttfile file can be constructed with a text editor and placed in a folder. The path to this file
is provided as the ttfile key/value pair. The 'indir' key/value option is the source directory where
this operation will do the filtering. The 'outdir' option is the default output directory that the
file will be moved to if no rule can be found in the tffile config file. Also, the 'archdir' is the
 default archive directory that a copy of the file will be placed if no rule can be found in the tffile
config file. The logfile option specifies the filepath of the log file that will record each file
movement event. Lastly, the 'doctypes' option allows you to only operate on documents of a
specific type...separated by commas. For example: 850,810,997 ….all other files will be
removed from the source directory and placed in archive. It is important to note that the files in
the source directory will be deleted whether you have a rule defined or not.

• TrafficDir This operation is similar in function to the X12DirFilter operation except that it
uses file naming convention as the primary factor of file distinguishing. Like it's counterpart,
the TrafficDir operation uses a tffile for the rules of file trafficking. Regex style wildcards can
be used within the rules for file identification. The tffile in this instance is comprised of
individual comma-delimited lines of 5 fields each. The first field is the file identification
pattern for the file. Wildcards can be used in this field. The second field is the destination
directory for the specific rule. The third field is an optional archive directory where a copy of
the file will be deposited. This field can be left blank as necessary. The fourth field is an
appending option that allows a hard-coded file to the destination directory. Any filename
pattern matching the rule will be appended to the filename in field 4. Field 5 is yes|no option to
delete the original source file within the source directory after the operation has processed the
rules. It is important to note that if a file is encountered that does not have a specific pattern
match, the file will remain in the source directory indefinitely. This operation requires a source
directory and a path to the log file as options in addition to the ttfile path location. The example
below shows the content of a sample ttfile with explicit rules and pattern file names for a
potential files found in the source directory. The first line indicates that any file whose file
name begins with "ACME" and has _997_ in the middle of the file name will be appended to
"acme_997.txt" in the indicated directory. The third line shows a pattern match for a file
containing "AMAZON_856" with subsequent characters that will be written to the destination
directory as is. Note that with regards to the third rule, if the explicit filename is already
present in the destination directory, it will be overwritten by the operation since the fourth field
is empty.

ACME.*_997_.*,//someserver/somedir/acme/outbox/,,acme_997.txt,yes
WALMART_810*,//someserver/somedir/walmart/outbox/,,walmart_810.txt,yes
AMAZON_856*,//someserver/somedir/amazon/outbox/,,,yes

• EmailDir This operation is similar in function to the TrafficDir operation in that it uses file
naming convention as the primary factor of file distinguishing. However, instead of moving
files based on rules in the ttfile, this operation send the file as an attachment to email recipients
based on rules in the ttfile. This operation assumes an smtp mail server is set up in System
Control (navcode=sysc). This operation takes 5 key/value options. The 'indir' option defines
the source directory of the files to be operated on. The 'logfile' option provides a place to name
the log file path that records the events of the operation. The 'ttfile' is the file path to the file
that contains the rules of email transmission that is associated with each file naming pattern.
There is also a 'archdir' path to place the file in an archive directory. If this is left blank, no
archiving will be performed of the original file. Note: The source file is deleted after the
operation. Finally, the 'smtpfrom' option is used for the sender email address.
The ttfile is comprised of colon-delimited lines of three fields. The first field is the file pattern
to use to identify the rule to apply for the file. The second field is used as the subject field in
the transmitted email. The third field is a comma-delimited list of email recipients. An
example content of the ttfile is provided below.
 ACME.*_997_.*: ACME 997 Acknowledgements:[email protected],
[email protected],[email protected]
WALMART_810*:Invoices for Walmart Report:[email protected]

• EmailFile This operation provides a method for transmitting a single file as an attachement to
an email recipient(s). It is comprised of 5 key/value options. The 'filepath' option assigns the
file path to the file being sent as an attachment. The 'smtpfrom' option defines the sender email
address. The 'smtpto' defines the receiver email address. You can provide a comma-delimited
value to this option for multiple recipients. The 'smtpsubject' option defines the subject line of
the email being transmitted. And finally, a 'delete' option to delete the source file after email
transmission. A value of 'yes' or 'true' to this option will remove the source file after email has
been transmitted.
• ScriptCall This operation provides a convenient method for calling a batch or script file at the
OS level from within a workflow operation. The 'source' key/value option must be the full path
to the executable script. The script can be a .bat, .ps1, .sh or whatever executable is targeted.
Parameters are passed in the 'parameters' option. This is a comma-delimited entry for multiple
parameters. The 'directory' option is an optional start-in directory.
Note: for powershell scripts, assign the value 'powershell' to the 'source' value and assign the
absolute path to the .ps1 script in the 'parameters' option. You can add additional parameters
after the .ps1 script in the parameters option separated by spaces.

The return value of the executed script does not return any values to the next operation in the
work flow, but any standard output from the ScriptCall operation is written to the work flow log
entries and can be visible in the Work Flow Log Browse (navcode=wkfl).
• Decrypt This operation will decrypt one or more files in a specified source directory. This
operation has 3 key/value options. The key id option identifies the encryption/decryption key
in the PKS Maintenance menu (navcode=pksm). The second and third options are the source
directory and destination directory to place the decrypted files. All files in the source directory
will be operated on with the decryption key. Successful operations will drop the decrypted file
in the destination directory.
• Encrypt This operation will encrypt one or more files in a specified source directory. This
operation has 3 key/value options. The key id option identifies the encryption key in the PKS
Maintenance menu (navcode=pksm). The second and third options are the source directory
and destination directory to place the encrypted files. All files in the source directory will be
operated on with the encrypted key. Successful operations will drop the encrypted file(s) in the
destination directory.
Figure 17.11.1
17.12 EDI Utilities

BlueSeer has several utilities that facilitate working with EDI files and directories containing edi
documents. These utilities can be used to traffic files from one directory to another or filter a directory
for specific document types and trafficking these specific documents to other directories for processing.
The java class “com.blueseer.edi.EDIbs” has several methods that can be executed depending on the
parameters passed to it when executed at the command line. These parameters are used in combination
with other parameters to call a specific method within the EDIbs class. The EDIbs class contains a
'main' method and can be wrapped in a simple bash script (linux) or bat script (windows). A simple bat
script (etran.bat) is shown here :
Contents of bat File: etran.bat

Once you have your bat or bash script set up and assigned as executable, then you can call it with
various combination of parameters to perform certain functions. These functions are listed below :

17.12.1 Utility: Filter Directory For Various X12 transaction types / partners

-fd (Filter Directory). This method parameter is the 'key' parameter used to filter a directory that
contains any type of file(s) for specific types (ANSI X12 doc types) of files and further overloaded by
the 'definition file' using the -tf parameter. Any file in the targeted directory that matches an element in
the transaction type list and/or definition file is processed to the target directory. All other files are
simply archived (along with processed files) and all files are subsequently deleted from the source
directory.
Here's an example:
./etran.bat -id C:\temp -od C:\targetdir\ -fd 850,997 -ad C:\archivedir\ -tf defFile >>filterlog.txt

The source directory specified by '-id' parameter is “c:\temp” and contains a collection of files. The
above command will review each file and process only files containing ANSI X12 850 purchase orders
and 997 acknowledgments as defined by '-fd' (a comma delimited collection of types). These files will
be copied to target directory '-od' by default. Each file that is reviewed in source directory will be
archived to archive directory specified by '-ad' parameter and all files within c:\temp will be deleted.
The '-tf' parameter (definition file) has parameters that will allow for certain combinations of
transaction types and trading partners (as defined by ISA06 Sender ID) within the file to overload the
target directory (-od) with a more specific directory as defined within the -tf definition file. The
contents of -tf defFile are defined as each line contains 4 fields delimited by a comma. Field1 is the
X12 transaction type, Field2 is the ISA06 SenderID, Field3 is the overloaded target directory, and
Field4 is the overloaded archive directory. This file is read during execution to determine which
transaction type / trading partner will overload the default target directory as defined by the -od
parameter and send the file to the alternate directory as defined by Field3 within the definition file.
Here's an example of the -tf definition file :
850,WALMART,c:\other\targetdir\,c:\other\archivedir\
850,AMAZON,c:\some\other\target\dir,c:\somedir\
997,,c:\still\some\other\directory\other\than\-od,c:\somedir\
Note: If Field2 is left blank...all files of the transaction type will go to the alternate target directory.
Note: You must include the trailing backslash “\” on the -od and -ad parameters and Field3 and
Field4 of definition file.

17.12.2 Utility: Simple File traffic utility with Append Option

-td (Traffic Directory). This method parameter is the 'key' parameter used to simply traffic (move)
files from one directory to another based on rules in the definition file -tf parameter. Any file that
matches a rule in the definition file is moved to the target directory defined within Field3 of the
definition file. If a file does not match a rule, the file is left untouched in the target directory. This is a
true 'move' of files that match as the file is deleted from target and copied to directory defined by
Field3 in the definition file.
Here's an example:
./etran.bat -td C:\temp -tf defFile >>filterlog.txt
The definition file contains 4 comma delimited fields. (This is not to be confused with the definition
file of other methods). Field1 is the string used to match the filename. Field2 is the destination
directory of the filename that “matches” Field1. Field3 is the archive directory. Field4 is an overload
field that if not blank, all files that match this rule will be appended to the file as named by Field4.
Note: Field1 is a 'contains' match. if Field1 is “abc”, any filename that contains the characters “abc”
will trigger this rule.
Here's an example of the -tf definition file :
customer_810,c:\outbound\invoice\directory\,c:\archivedir\,810_appendfile.txt
customer_856,c:\outbound\asn\directory\,c:\archivedir\,
Any file in the source directory -td that contains the string “customer_810” will be “appended” to
c:\outbound\invoice\directory to a file called “810_appendfile.txt and the original source file will be
deleted from the source directory and archived to c:\archivedir.
Files matching “customer_856” rule will not be appended per the rule above since Field4 is blank.
18 Custom Application Guide

18.1 Customization Overview

One of the best features of BlueSeer is it's ability to customize the core package or extend
functionality by creating new classes. The parent menu 'custom' is childless by default. You can create
your own java JPanel class and include this class under the custom menu. There are a few constraints
to observe when adding custom applications, but the functionality you add to your custom JPanel class
can be completely independent from the core BlueSeer package albeit a few minor exceptions. The
minimum requirements for a custom JPanel class are:
1. The class you create must be a JPanel class. BlueSeer is essentially a large collection of JPanel
classes. Each Class is associated with a Jmenu option in the parent frame and is 'selected' by
clicking on the associated menu. The act of selection essentially pulls the selected JPanel
forward (visible = true), and all other JPanels have their visible flags set to false.
2. The class you create must exist in a java package called 'custom'. For example, if you create a
class called 'myclass', it must reside in a java package as custom.myclass.
3. The jar file that contains custom.myclass for example, can be named anything. However, it
must be placed in the -cp path prior to the blueseer.jar file. For example, the following java
command line statement is legitimate (assuming you called your jar file 'custom.jar' and placed
in the dist directory) :
javaw -cp dist\custom.jar;dist\blueseer.jar bsmf.MainFrame
Note: you must ensure that your 'myclass' is defined in the 'custom' package within the
'custom' jar file. You should be able to see your custom class with the following jar
viewer command :
jar tf dist\custom.jar |find “myclass”
This command should return : custom/myclass.class
4. You should include bsmf.jar file in your library when you compile your custom package. The
bsmf.jar file is the primary JFrame which controls the panels and navigation of the application.
Including blueseer.jar is optional, but recommended if you plan to use any classes within the
core package.
5. Lastly, you will need to update a several Maintenance records within the BlueSeer application
once you've launched blueseer to 'include' your custom class within application.
◦ Admin → Class Register
◦ Admin → Menu Maintenance
◦ Admin → User Perms Maintenance
◦ Admin → Menu Tree Maintenance
18.2 Customization Example
The following steps illustrate the creation and inclusion of a sample Java JPanel Class to the
BlueSeer Application :

1. Let's create a simple Java JPanel Class. We will use NetBeans IDE to create a JPanel
class.
2. Within NetBeans, create a new Project by clicking on File → New Project and choosing
'Java Application'. Click Next. Enter the name 'myproject' as the name of the project
and click Finish. (see screenshots below).
3. Right Click on your newly created project 'myproject' and click 'New' → 'Java Package'.
Enter 'custom' as the Package Name and click Finish.
4. You should now have 'custom' as the only package in Source Packages.

5. Right click on the 'custom' package and click 'New' → JPanel Form, enter 'myclass' as
the class name and click Finish.

6. Now that you have an empty panel, let's drag a Jbutton and a JtextField over into the
panel. Highlight both components and right click and choose 'Enclose In' Panel. This
will place the two components within a small panel (jPanel1). Your components should
have the following hierarchy in the image below.
7. Right-click on the outer panel (jPanel) and click 'Set Layout' and choose Flow Layout.
Your project structure should look like :
8. You will need to add a single function to your source code called 'initvars(String)'. It
just needs to be declared. It is used by bsmf.jar for initialization purposes.

9. Lastly, double click the jButton1. You will be navigated to the

jButton1ActionPerformed function. Inside this function write the following statement:
◦ jTextField1.setText("BOO");
10. Now that your coding is complete, right click on the 'myproject' icon and click 'Clean
and Build'. This will create your jar file for you. The jar file is labeled 'myproject.jar' in
your dist directory. You can see the location of the jar file in the Output screen as shown
here:

11. Now it's time to insert your newly created class into the BlueSeer application flow by
including the jar file in your class path and registering your class with the application.
12. Copy the 'myproject.jar' file and place in the c:\blueseer\dist directory.
13. Adjust your java launch path (in login.bat if you installed the demo) to include this jar
 file like so (on windows):
javaw -cp dist\myproject.jar;dist\blueseer.jar bsmf.MainFrame
14. Launch Blueseer either with the javaw statement above or from your 'edited' login.bat
file.
15. Once launched, click Admin → Class Register. Click 'New' and enter 'myclass' in the
class ID field and click 'add'.

16. Click Admin → Menu Maintenance. Click 'New' and enter 'MyNewMenu' in the Menu
ID field and 'myclass' in the Class ID field. Then click 'add'. Do not check parent menu
only.
17. If you are using the 'admin' login in BlueSeer, the creation of the menu automatically
creates permissions for 'admin' to use that menu so you don't have to do this step. Any
other users will have to have their perms adjusted to use the menu in Admin → User
Perms Maintenance
18. Enter 'sysc' in the navigation text-box. This will bring you to the system control menu.
Click the 'custom' check-box. This checkbox informs the system that custom panels are
present in the classpath.
19. Finally click Admin → Menu Tree Maintenance to add your new menu to the menu tree.
Enter 'Custom' in the Parent Item and tab to the Component field. This drop down box
is 'editable'. Enter the 'component' of your new menu 'MyNewMenu' that was
previously created in Menu Maintenance. Tab down and enter a descriptive name like
'My New Menu' (this will be visible portion of the menu to the enduser). Choose
JmenuItem, check Visible and Enabled and click 'Add'.
20. Before you will see your new menu under the Custom Menu, you will need to close the
application, and re-launch BlueSeer. (Note: BlueSeer registers all menu at time of
launch. Changing the menu tree structure will always require a re-launch to see the
changes).
You should now be able to click on the Custom Parent menu and your 'My New Menu'
to see the results of your new class code. Enjoy! :)
19 Appendix

19.1 Miscellaneous MySQL one-liners

# mysql location of config file on Windows
C:\ProgramData\MySQL\MySQL Server 8.0\my.ini
# mysql backup from powershell
mysqldump -u root -pxxx bsdb > C:\MySQLBackup\bsdb_backup.sql
# mysql restore from powershell
Get-Content bsdb_backup.sql | mysql -u root -pxxx bsdb
& cmd.exe /c "mysql -u root -pxxx bsdb < bsdb_backup.sql"
# mysql copy scenario from powershell to copy bsdb to bstemp and upgrade bstemp
mysql -u root -pxxx -e 'drop database bstemp';
mysql -u root -pxxx -e 'create database bstemp';
mysqldump -u root -pxxx bsdb |mysql -u root -pxxx bstemp
#mysql command prompt miscellaneous statements
SHOW GLOBAL VARIABLES LIKE 'local_infile';
SET GLOBAL local_infile = true;
select user, host, db, command from information_schema.processlist;
select user from mysql.user;
SELECT * FROM information_schema.user_privileges;
SELECT host, db, user, select_priv, insert_priv, update_priv, delete_priv FROM mysql.db
WHERE db = 'bsdb';
drop user if exists 'bs_user'@'%' ;
create user if not exists 'bs_user'@'%' identified by 'xxxxx';
grant select,insert,delete,update on %DB%.* to 'bs_user'@'%';
create database if not exists %DB% character set utf8mb4 collate utf8mb4_unicode_ci;
# commands to create new db instance from backup and upgrade
echo 'drop database bsdb67;' |mysql -u root -pxxxxx
echo 'create database bsdb67;' |mysql -u root -pxxxxx
gc db.backup |mysql -u root -pxxxxx bsdb67
gc upgrade65to67.sql |mysql --local-infile=1 -u root -pxxxxx bsdb67
echo "grant select,insert,delete,update on bsdb67.* to 'bs_user'@'%';" |mysql -u root -pxxx