Rev 10 Resource/Samples Page


This page outlines selected NetLink changes in Revision 10 of the SouthWare Excellence Series and provides examples and resources for using Rev 10 features.  There are other Rev 10 features but these are ones that are particulary useful for NetLink developers who create their own pages.

You can cut and paste the sample HTML from the text field in the gray box at the bottom of a concept to help with your own applications.  (The text field is used because if you cut from the text on a browser page and paste into an HTML document the HTML code may not be in the proper syntax.)

Using RCF Packets with NetLink

You may now launch a SouthWare RCF Packet from a NetLink request! This lets you use a web page and browser to execute virtually any process that you can automate with an RCF Packet.

This has ENORMOUS potential power for your NetLink users:

L With SouthWareís RCF (Remote Control Fields) Packets you may automate literally hundreds of SouthWare options. See XX-09-14 in the SwiftMate manual for more information.

L With the ability to launch an RCF packet by simply clicking on a link in a web page that calls NetLink you can now utilize the power of RCF Packets from any browser in the world!

For example, you can create an RCF Packet that runs in invisible mode to:

  • Update ExecuMate II Gather Info
  • Post Transactions (e.g. be able to post receivings from a handheld web page)
  • Run I/S End of Day Update
  • Run a print program with parameters to spool a file
  • Do literally hundreds of other automated tasks

Then you can launch the RCF Packet from a NetLink request to automate the same functions you would otherwise perform from a normal SouthWare logon session.

Specifying that an RCF Packet should be run by a Request

In the request record you may now define an RCF Packet as the Secondary Program (NL-01-02, field 9, "Secondary Program"). You may enter the syntax:


where xxxxxxxx is the name of the RCF Packet object to be launched. For example, if you entered "@RCF=XMGATHER" the request would be configured to launch the "XMGATHER" object/RCF packet at the timing you specify in the "Secondary Timing" field.

Note: Any RCF Packet you specify should be tested and configured for "invisible" mode (XX-09-14-01, field 4 = "Y"). The normal user interface for any program is not available to a web browser. If the program does not run successfully in invisible mode the browser will "hang" when you run from NetLink.

Launching the RCF Packet from a NetLink page

When you call a NetLink request that has an RCF Packet as the secondary program the NetLink program will launch the RCF Packet at the "Secondary Timing" point specified in the request.

WorkFlow in RCF Packets

If you run an RCF Packet from NetLink any WorkFlow FlowMods in the packet will be executed. WorkFlow is not normally available in NetLink but the RCF packets that utilize WorkFlow will be able to execute FlowMods.

Check for Limitations

Make sure you test whether a process can be automated via an invisible RCF Packet. There may be program/data situations that may not be automated due to special passing or environment parameters.


Option to Switch User Login Within Same Session

A common scenario on a web site that sells items is to allow a customer to browse your catalog and select items for ordering without first logging in. Then when the order is ready to submit you allow the user to log in with their customer ID and password and switch the order information to their customer account.

A new feature in NetLink supports this capability. You may now switch a session from an "O" type requestor (Other) to a C, V, or I type requestor while retaining the other session information. This supports the order entry scenario above as well as other possible browse-then-login scenarios.

To support this feature there are three new reserved NetLink variables:




NetLink will look for these variables when the current requestor type is "O". These variables have the same meaning as the variables that donít start with "new_" except that they are used to switch the requestor for an existing session rather than to start a new session.

When NetLink finds these variables in the incoming values for an "O" requestor session it:

- verifies that the type/id/authorization are valid

- if valid, changes the session record to the new requestor info and changes the sessionís customer/vendor/employee number

Related Change to Standard NetLink Samples

This feature has been implemented in the standard sample page of "OPOSHDR" (the blank order header form displayed for an Other type requestor who decides to submit an order). This page now includes a login form for "Existing Customer" that uses these new variables. If the user submits a valid customer ID and authorization code from that form then NetLink will change the session to that requestor and customer. NetLink will then call "CORDHDR" so that the customerís default information will be shown in the order header.

Here is the HTML syntax for the related form:


Extended Data option for NetLink Order Header and Line Item Files

You may now use Extended Data fields to store additional information about pending NetLink orders. This is in addition to the user fields previously available for the NetLink order header and order line item.

These XD types let you temporarily store custom information about a pending NetLink order/line item before you submit the order. After you submit an order any needed data should be imported into the standard order header and line item fields and related Extended Data.

Two new reserved Transaction Extended Data types are available:

123 NetLink order header XD

124 NetLink order line item XD

You may define fields for these XD types in the Extended Data control record (XD-03-01). For each type you may also have up to 20 user-related types for a total of over 300 possible fields for each reserved type.

To accept XD fields in your NetLink page forms

You may define that a field in a web page form is to be stored as an Extended Data field via the name you give to the form field. The naming convention is:


where "tt" is the last two digits of the record type and "nnnn" is the Data Dictionary field number. For example, field 6 in the Data Dictionary for order header Extended Data would be "XT230006".

How NetLink saves NetLink order Extended Data fields

When the NetLink order entry routine is saving order header information (NLORDENT/H) it also looks for order header Extended Data fields ("XTttnnnn" for fields in XD 123 or related types). When saving order line item information (NLORDENT/L) it also looks for order line item Extended Data fields ("XTttnnnn" for fields in XD 124 or related types). When it encounters an applicable NetLink order Extended Data field it automatically stores it in Extended Data.

Displaying a NetLink order XD field in a page

These fields are accessible via ReportMate just like the standard NetLink order header and line item fields. You may output them in a report or as a variable value just like any other fields.

Importing NetLink order XD fields into standard SouthWare orders

When you submit a NetLink order the order data is written to a text file and then the standard SouthWare order is created via importing the text file data. The standard format of the text file is outlined in Appendix G of the NetLink manual.

If you have defined Extended Data fields for a NetLink order header or line item then the special NetLink order entry program outputs them into the text file data as well (NLORDENT/I):

- NLORDENT/I will export one new record for each XD record type (i.e. 123 and its related, 124 and its related).

- The 3-char record type will be the 3-digit XD record type (i.e. one text record for each XD record type, inserted at the proper place in the text file, following the HDR or DAT records).

- Fields will be output to the text record in field number sequence at 50-byte increments.

For example, the first few characters of the text lines for an order with both header Extended Data (123) and line item Extended Data (type 124) would look like this:

LBL desc1 desc2 desc3 (etc.)

HDR field 1 field2 field3 (etc.)

123 xd 1 xd 2 xd 3 (etc.)

LBL desc1 desc2 desc3 (etc.)

DAT seq# field1 field2 (etc.)

124 seq# xd 1 xd 2 (etc.)

In order to update NetLink order XD into the standard Inventory/Sales Order (and line item) Extended Data you must modify your import format to recognize and retrieve these additional record types. SouthWare does not have any standard samples of this since Extended Data is custom per user.

If you use the Multiple Stock Items per page feature

NetLink supports the ability to enter/edit quantities for multiple line items on a single page (see "Ability to Add/Edit Multiple Order Line Item Quantities on Same Page" in Appendix G of the NetLink manual). You may use this feature in conjunction with line item Extended Data:

- To have multiple stock items with Extended Data on the same page the XD syntax must include the literal that triggers the program for multi lines (ITEM_QTY_) and the stock number (last element). The Extended Data format for this kind is ITEMQTY_XTnnffff_(stockno). For example:

@VAR_ITEM_QTY_100 would be the variable to add a line item for stock number 100 where the actual qty to add is the value of the variable. The value of the form variable @VAR_ITEMQTY_XT240006_100 would be the data for XT24 field 6 data for the line item that contains stock 100. The stock number must be the last element so that embedded spaces cannot occur.


Special Limitations of these XD types

Because these Extended Data types are specially designed for use with NetLink pages they have related limitations:

- You may not define key fields or auto-XD fields in these record types

- Related notes are not available for these files


Ability to Copy a NetLink Order

You now have the option to create a new NetLink order by copying an existing NetLink order. This was requested so that you may allow a customer to copy a previous saved order into a new order.

This feature is implemented via a new reserved NetLink variable:


where "nnnnnnnn" is the number of a saved NetLink order. When NetLink encounters this variable it does the following:

  • Creates a new order number from the current session info. NetLink pending order numbers are derived as follows
    • The first 8 chars of the order number is the session#
    • The last 3 chars of the order number is the request counter (the request counter that started the order).
  • Copies the order header, order line items, and any Extended Data from the "copy" order into the new order.
  • Changes the session info to refer to the new order number.

Submitting a number via a form

The sample page includes a form that submits an existing order number to be copied.  It calls the CORDER request to show the new pending order:

And here is the HTML syntax for a form that you could insert in a page:

Submitting a number via a link

From a list of pending orders or from the CORDER page you could also add a link to copy the order.  You would simply use the existing order as the value for "nl_copy_order_no" and call CORDER.  The syntax is below:


New Marketing Catalog Option for Item Selection Pages

A new sample NetLink request uses the Inventory/Sales Marketing Catalog as a method of reviewing/selecting items to order in NetLink. If you use the marketing catalog you can replace the product category selection (QCCATSEL) with your own version of this sample. The sample request type is CMKTSEL and uses the following elements:

  • ReportMate format of NLMKTCAT to show items from RS27, the marketing catalog (includes both categories and stock items)
    • The format will output an image for categories or stock items if the related image name is not blank.
  • ReportMate parameter record for NLMKTCAT that uses the NetLink Table Format record of MKTCAT for a 3-wide table.
  • HTML template of nlmktsel.htm

To call the catalog for the first level of records you must use a string such as the sample below:

The sample page includes a sample link for the Marketing Catalog.

Item Group Matrix Grid 

A new set of sample NetLink pages uses the Item Group Matrix module to show items available within a group. You may optionally use this to display a matrix group entry grid for entering items on a sales order. Here are the related requests:


This request accepts a starting group/style value and calls to CMATRIXLIST. You could easily embed this html form into another page to provide easy access to the list of groups/styles.


This request produces a list of groups. The starting value can be provided via the variable "group_start_id" or this can be blank to include all groups. The related ReportMate format (NLMATLST) has a limit of 30 records with a next page option.


This request produces an entry grid for quantities to be ordered within a matrix group. The entry form calls to request QCORDLIN to submit the quantities and add them to the order.

The grid uses two ReportMate formats to output the entry table and uses a table format of MATRIX that does not output any row tags:

- The format NLMATCOL will output the column headers and the tags for the first row.

- The ReportMate format NLMATENT will output the rows and entry fields for each row. It contains embedded HTML syntax to produce table rows/columns that match the group rows/columns (up to ten columns in the sample). It uses the Table format of MATRIX which suppresses all automatic row formatting so that the row tags are controlled within the ReportMate format.

Here is the syntax to call the Find function to enter a starting group value:

The sample page includes a sample link for the matrix find function.

Option to Continue Table Cell on Next Line of RM Format

You now have the ability to use multiple ReportMate format lines to provide the contents of a single cell within an HTML table.


In prior revisions ReportMate automatically assumed the start of a new cell when starting a new line in the format. This is typically the case and works in most situations. However, if you have a lot of text to output into a single cell (such as multiple lines of text from a TaskWise task) this limited the contents of a cell to the text that would fit in a single format line.

With this feature you may place a continuation indicator at the end of a format line to specify that the next line is a continuation of the same cell. Place an underscore (_) in the last character of a format line to specify that the next line should be a continuation of the last cell on this line.

For example, if you are defining a 264-column format you could place an underscore in column 264 of a line to disable the automatic start of a new cell on the next line.

Standard ReportMate samples that use this feature include NLMKTLST and NLMATENT.


Option to Control Records Per Table Row

With this feature you may specify how many records to include in a table row created via ReportMate. This allows you to:

L Place multiple records in a single row for a multi-column presentation of data such as names or categories.

L Disable any automatic table rows so that you can conditionally insert table row tags into your ReportMate format.

This feature is implemented in the NetLink Data Table Format record (NL-01-05). In field 11 Advanced Features you now have the following option:

# of Records Per Row:

Specify how many reporting records (from the primary file) should be included in a single table row. For a Totals Only report this count will apply to the last subtotal level. This defaults to "1" which is the typical structure of a table (one row per record).

- You could enter a number greater than one if you plan to use this table format to create lists with multiple columns of records. For example, if you enter "3" in this field the report will output three records for each table row which should result in a three-column table. A standard sample of this is the request CMKTSEL which uses the table format of MKTCAT to produce a 3-wide display of marketing catalog entries.

- You could enter "0" here to suppress all standard row tags from the resulting table. This would allow you to code the row beginning and ending tags within your format so that you control the rows based on the data. A standard sample of this is the request CMATRIXENT which produces an entry grid by inserting the appropriate row tags when a new row is needed.


Option to Pre-define Variable Names as ReportMate Parameter Values for Increased Security

You may now use Data Dictionary variables as the values of NetLink ReportMate parameters (NL-01-04). If the value needed for a ReportMate parameter is available as a variable from the NetLink session file (NL03) you can "hard code" the parameter to the variable. This eliminates the need to pass certain values in the post/get strings for NetLink requests. By removing certain variables from the post/get string you donít "expose" the variable to users.

This is particularly helpful for internal user requests since it helps prevent web-savvy internal users from trying to manipulate post/get strings in an attempt to access internal data. It is less useful for customers and other requestors since NetLink already prevents a customer from changing the customer variable.

In any NetLink ReportMate parameter field you may enter a variable as


where XXXX is the Data Dictionary file and 9999 is the field number of a field available from the NL03 pathing. For example, on a request where you are displaying info for a salesperson you could use the variable <@DD=PR010139> to reference the salesperson number in the employee record for the current internal operator. This would eliminate the salesperson value from the post/get string.