Frame Inventory Implementation

The files used for frame inventory (so far) are:

RXFSTOCK.* - copybooks ??FSTK.CPY - frame items - technical data, but not bin or quantities, since those can vary by warehouse.

RXWSTOCK.* - copybooks ??WSTK.CPY - warehouse detail for frames - note, this file has been structured so that it can be used for lenses as well (it is not restricted to frames in the future).

RXWAREHS.* - copybooks ??WAREHS.CPY - warehouses - right now consists of just code and name

RXFSTX.* - - copybooks ??FSTX.CPY - frame stock transactions, note this file includes warehouse ID since transactions are always against a particular warehouse

Basic BREAD functions for frame inventory and warehouse file are done in bread_frame.cbl and bread_warehouse.cbl, using new standard copybooks for BREAD functions.

Programs used by endpoints

bread_frame - provides R[ead], [E]dit, [A]dd and [D]elete functions for the RXFSTOCK file.
bread_framewh - provides R[ead], [E]dit, [A]dd and [D]elete functions for the RXWSTOCK file.
bread_warehouse - R[ead], [E]dit, [A]dd and [D]elete functions for the RXWAREHS file.
bread_framestx - R[ead], [E]dit, [A]dd and [D]elete functions for the RXFSTX file. The add, edit and delete functions might not be used, since transactions will normally be created by events, which also need to update the frame warehouse record (quantities, etc), but is included in case we need them. The read functions will definitely be used to display transactions for a particular frame, purchase order, maybe order, etc.

We are not maintaining tables for the different names, brands, collections, colours, manufacturers, or models. Rather, we have programs which use multiple start statements to get a list of all the different values used in the frame file, and return that list for use in dropdowns on the web page. These programs are named “frame_brands”, “frame_collections”, etc.

There are two endpoints for trace records:
frame_traces - returns a list of trace record keys which match the beginning of the name (passed in the request).
frame_trace - accepts a trace key and returns a 180-point array to display the trace on the screen

Structure of BREAD functions

There are two copybooks that handle the basic Browse, Read, Add, Edit and Delete functions - api-read.cpy and ws-api.cpy.

In “api-read”, there is one entry point, “read-functions”, which accepts inputs for the function type (only options are R, E, A, D), the value of the primary key (used for the edit, add, and delete functions), which key to use (optional, used for the read function), and the values for the first and last key values (again, for the read). If only the first-key is specified, with no last-key, then only one record will be returned.

In the main program for the file to be maintained:

  1. include WSAPI.CPY copybook in working storage, and the READ-API.CPY in the procedure section.

  2. The main section of the program will be very simple:
    move menu-number to ws-menu-value - menu-number is the value of the permissions table for the appropriate option in Rx-Universe
    perform READ-functions

  3. the specific program will contain paragraphs specific to the file:
    open-files
    close-files
    start-file (which should use the appropriate key and first/last key values)
    read-record (which should use the appropriate key and first/last key values)
    read-next-record
    write-record
    rewrite-record
    remove-record (for deleting)
    process-label-array - unique to each file, populates the record with values from the API argument file
    validate-record
    generate-record-json - creates the response, which will be different for each file because of the different record contents