VisionWeb Catalogue Considerations with Rx-Universe

Owned by Tony LeBlanc
Last updated: Mar 25, 2022
8 min read

Catalog Considerations

When setting up the Vision Web Catalog, remember that what is contained in the “Convert” fields is what is used within Rx-Universe.

When creating the Job Types and Frame Status:

We check the following values in the FRAME section:

Action
”NONE” = uncut
”NONE” or “PRES” - no frame

ActionName
”Lens Only” - we set to “Lens only”
”Frame to come” - we set to “Frame To Follow”

ALL OTHER VALUES will set “Supply Frame”

So, value TBP, “To be purchased”, would be interpreted as a supply frame job; since there is no actual “Supply Frame” status listed in the VW schema, this would typically be the selection for Supply Frame.

When supply frame is used, and no UPC is supplied, the BRAND, COLOR, MODEL, EYESIZE, BRIDGE TEMPLE and TYPE must all be entered exactly as they appear in the Rx-Universe stock record.  Vision Web has no ability to enter frames separately within their catalog (this is a future enhancement for them).

Catalogue Links to Rx-Universe

Items are set up in the VisionWeb catalogue in families and groups, and information from these different groups are interpreted by Rx-Universe in different ways.

In the catalogue, there are several fields which describe the item, describe how the item will appear to the user, and define what gets sent to the LMS.  The “Convert” column is what gets sent to the LMS, so the contents of that column are critical to correct handling of the order by the LMS.

For interfacing with Rx-Universe, the DESIGN family will determine the lens style to be used – the value of the “Convert” column should contain the Rx-Universe lens style code used by the lab.

The MATERIAL family describes the material code, and sometimes the color and pretreatment of the lens.  This would be true for lenses which always have a color and/or pretreatment, such as photochromatics or polarized lenses.  When used, the format of the material must be “M-CCC-TTT”, where M is the single character Rx-Universe material code, TTT is the 3-character Rx-Universe pretreatment code, and CCC is the 3-character Rx-Universe tint code.  So, a 1.5 index Transitions VII Gray 3 lens would have a “Convert” value of “T-GY3-TR7”.  Note that the format is important – the color and treatment must be 3 characters, even if some of the characters are spaces.

The TREATMENT family describes a treatment which may already exist on a lens, or which may be added to a clear lens.  For example, a color such as GY3 might fall into that category – a poly lens might be available in GY3 tint, and if not, the GY3 would be applied as a solid tint to a clear lens.  Both the setup in VisionWeb and the setup in Rx-Universe are important to ensure it gets handled the way the lab prefers.

In the above example, for a basic AR coating, where the LMS should select a pre-coated AR lens (if available), and a clear lens if not available, the VisionWeb catalogue item would be set up, in the TREATMENT family, with a “Convert” code of “ARC”.  This will cause ARC to be inserted into the pretreatment field in Rx-Universe – from that point, blank selection rules apply just as if an order were being manually entered and ARC entered in the pretreatment field.

Rx-Universe will look for a lens with ARC in the pretreatment field – if found, it will use that lens.  If a lens with that pretreatment code could not be found, then Rx-Universe checks to see what kind of pretreatment that code is.  If ARC is set up as an optional pretreatment, which means it can also be applied to a clear lens, then Rx-Universe will check for a clear lens and select that if available.  In this case, the lab should ensure that a PT pricing addon is set up, which will cause the ARC to be inserted on the addon screen, ensuring that it gets printed as a requirement on the work ticket.  If job flow is being used for tints, this will also cause the AR required flag to be set for the order.

If ARC was set up as a non-optional treatment (for example, POL would be non-optional, meaning that the lab cannot apply it, it must be present on the lens blank), then Rx-Universe will not consider a lens without that pretreatment when selecting lenses.

Note that the MATERIAL takes precedence over the TREATMENT family – if UV was set up as a TREATMENT, Rx-Universe would check the pretreatment field for the order – if it had already been set (by the material, for example), then the TREATMENT item would become an addon on the addon screen.  This is exactly what an operator would do if entering an order like this manually.

There are some specific rules associated with the TREATMENT family – if the family is “AR”, “ARHC”, “HC”, “SRC”, or “UV”, then the TREATMENT is a pretreatment in Rx-Universe.  If the family is “COL” or “TINT”, then the TREATMENT item is consider a color (tint) in Rx-Universe.  Any other family will be treated as a manual addon in Rx-Universe.

Frame Status is determined by the “Convert” field of the FRAME family – a value of “TC” indicates Frame To Come (Frame to Follow), and causes the Rx-Universe frame status to be set to “F”.

Edge Type is set by the “Convert” column of the FRAME item, as follows:

“SPA”    - Rx-Universe sets the frame type to the default Safety Frame code

“ZYL EDGE” or “1/2 EYE ZYL” – Rx-Universe sets the edge type to the default bevel type

“METAL EDGE” or “1/2 EYE METAL” – Rx-Universe sets the edge type to the default metal type

“DRILLED RIMLESS” – Rx-Universe sets to the default drilled rimless frame type.

“GROOVED RIMLESS”, “FULL METAL GRV”, PAINT GROOVE” or “1/2 EYE RIMLESS”, Rx-Universe set the frame type to the default groove lens style

“FACET” or “DOUBLE FACET” – Rx-Universe sets edge type to the default Facet type


Lens Codes and Material Codes in the Catalogue, and Rx-Universe

Rx-Universe traditionally has used different lens codes for polarized lens styles as compared to the non-polarized version.  For example, PST28 is used for a polarized ST28, POLSV is used for a polarized SV, etc.

Similarly, Rx-Universe uses different material codes for different indices of materials.  For example, three material codes (A, F and X) are used to represent different 160 polymers in Rx-Universe.

When dispensers create orders on visionweb.com, the appropriate codes are sent to Rx-Universe from the “Codification” fields in the VisionWeb catalogue.

However, when transferring orders electronically from one system to another through VisionWeb, the use of different codes causes problems for the translation process in VisionWeb. A practice management system, for example, could have their catalogue set up with only one material code to represent 160, and not have the specific lens product combinations set up, like you would find in an LMS catalogue.  When an order for a 160 is sent to an Rx-Universe lab, there’s no provision for VisionWeb to convert a single 160 code to multiple Rx-Universe 160 codes, because there’s no link to the particular lens style used.

In a similar vein, when Rx-Universe sends orders out to other labs, the use of ST28 and PST28 to represent a single VisionWeb Ref Code (for Flat Top 28), causes a breakdown in translation.

To get around these two limitations of VisionWeb, the lab can opt to use a single value to represent materials in the VisionWeb catalogue, and a single lens design to represent the polarized and non-polarized versions of lens styles in Rx-Universe, and use the Rx-Universe alias settings to select the proper lenses. 

In the examples given, the VisionWeb catalogue would be set up with a single material for all 160 products – for example, material code “A”, instead of using “X” for Essilor 160 products, for example,  Then, in the Rx-Universe alias file, alias entries for each lens design that is listed as material “A” in the catalogue, but exists as material “F” or “X” in Rx-Universe, would be created.

Consider the Essilor 160 Accolade progressive. In Rx-Universe, this is coded as ACCOL in material X.  Other 160 products are coded as A or F, depending on the index of refraction.

In a typical Rx-Universe VisionWeb catalogue, more than one material would be set up for 1.60 resin:

Then, the lens design would be set up:

And the lens itself would be set up:

To allow VisionWeb to correctly translate codes from a practice management system, for example, the material codes need to be consolidated into one code per material – in the case of the 160 materials, instead of using A, F and X, use only one code.  Thus, all VisionWeb catalogue entries set up with materials X and F would be changed to use material A.  In the example above, only the lens table entry would need to be changed:

Thus, the codification sent to Rx-Universe for an Accolade 160 would now be A-ACCOL instead of X-ACCOL.  To allow Rx-Universe to correctly choose the right material (code X), an alias entry would need to be created in the alias file for the "ACCOL, A" as follows:

No changes to pricing or inventory would be needed, as Rx-Universe will convert the incoming A-ACCOL to pick the X-ACCOL lens, which is what would be priced and tracked.


Vision Web (Lab-to-Lab) setup

The Vision Web Lab-to-Lab is supplied to Rx-Universe users as a separate module that must be purchased separately.   The module will be activated by an Rx-Universe support rep once confirmation of purchase has been received. 


Remote Lab settings

Once the Vision Web Lab-to-Lab module is activated, you will be able to select this method when setting up your remote labs for order transfers.  (Refer to the Lab to Lab Order Transfer section for complete information). 

To activate a remote lab for Vision Web transfers, set its Communication method to “VisionWeb”.  You must also create a remote lab entry for each lab that you want to send orders to via VisionWeb; your lab account number identifies your lab at the receiving end of the Vision Web transfer.  The VisionWeb Supplier-ID is the identification # used by VisionWeb for the destination Lab. 

Running Vision Web Lab-to-Lab

To activate the Vision Web interface, “Use Vision Web Interface” in the Remote Order Processing Options screen must be checked and the Transfer routines within the “VisionWeb Options” screen must be set to “Receive and Send Orders” or “Send Orders (lab-to-lab)”.

Any orders that have been identified by the Lab-to-lab transfer rules as orders to transfer, and the lab that they are being transferred to is using the VisionWeb Transfer method, these orders will be sent via the Remote order processor during the Vision Web portion of the procedure.  The Remote Processor checks the Order transfer file and any orders that have been identified as using the VisionWeb transfer method will be transferred to VisionWeb.   The Vision Web transfer dialog screen will display the order numbers that are being transferred on the screen.