The logic of Orderoptions has been completely restrucutured on 12.07.2017

This ist the old Version and is displayed just for Information.

To see the new version of orderoptions see this page

Overview usage

Sonderfälle, die beachtet werden müssen.

Orderoptions are used to define which values can be or need to be transmitted at ordering a product (lens or option). In version 6 (SF6) this was the orderoptions.dat, which is extended by the posibility of a combination logic.

The core element is the orderoptiongroup. Here a list of orderoption types can be defined with “optional” or “mandatory” for every item. In one group an orderoption type can only be listed once. The elements in a list need to be all complied (Boolean AND conjunction).

• mandatory: the value is needed for this lens/option, it can't be ordered without it.
• optional: the value can be transmitted in an order, but the lens/option can also be ordered without it.

If an orderoption type is not defined it should not be transmitted in an order. It will not be used in lens calculation and production.
This part is very similar to the implementation of orderoption.dat in version 6 (SF6).

It is now possible to concatenate orderoption groups. Then you can split the list of types. The link to the next group is set in the current group.
One of the linked group need to be complied with the current one (Boolean AND conjunction). If more than one group is linked in the current group, only one path is possible (Boolean XOR conjunction).

The orderoption groups are listed in the orderoptiongroups element. Every group needs to have an numeric id. This id needs to be unique in the catalog.
Optional an internal description for a group can be set. This should not be viewed to any user. It is only for company internal purposes.

The root of every branch is a orderoption rule.
If you need different branches of orderoptions when an option is combined with another option or a lens is combined with an option, you define more than one orderoption rule. Then you use the matching part, where you define the lens or option as filter.

The orderoption rules are listed in the orderoptionrules element. Every rule needs to have an numeric id. This id needs to be unique in the catalog.
Optional an internal description for a group can be set. This should not be displayed to any user. It is only for company internal purposes.

At the lens and option the orderoption rule is referenced by the id. If there is more than one rule listed, a priority number is mandatory. Every list item needs a different number, so it is unique for this list. The order is from the smallest to the highest number. The first rule where the matching-part match with the current selection of lens and options, is the valid branch of orderoptions.

MIS and EyeRotationDistance

Prio 1, the first branche shows the information needed if Option Metris (OrderOptionsGroup1) is combined with the lens. In OrderOptionsRule1 all exept BVD is needed. MIS and PD or (inset, first-/last-name, …)

Prioritisation is not needed if only one branche is made.

Prio 2, the second branche shows information beginning with only lens and OrderOptionsRule2 and OrderOptionsRule1 must be fullfilled.

BVD and PD or (inset, first-/last-name, …)

The option Metris need the orderoption EyeRotationDistance.

3 Option Metris - OrderOptionGroup is empty, OrderOptionRule- EyeRotationDistance is needed.

The lens “HP ysis intuitiv Nah 1m 1.5” needs the orderoptions BVD (back vertex distance) and PD mandatory, and optional inset, customer first-, last-name, objectdistance near, midde and handedness (see table).

Below the flow-sheet is an overview of the OrderOptions. Prio 1 has priority over Prio 2

HP YSIS intuitiv Nah 1m 1.5

Metris

Summary and Results

So far in SF6 the combinations of this lens all parameters had te be send. It only needed b' and BVD. With LC7 it is made visable using OrderOptionsGroups, OrderOptionsRules and a prioritization. The picture shows how these elements are placed.

Top;

OrderOptionsRule 1: Handedness (or Designtype)

Prio 1;

OrderOptionsRule 2: MIO and (BVD and PD and … ObjectDistance Near) (or Designtype)

Prio 2;

OrderOptionsRule 3: FOR and (Monocular centration distance and Boxwith and … Shape tracerdata) (or Designtype)

HP ANATEO intuitiv 1.5

MIO

Remote edging

Summary of variants according to matching

Eliminate redundancy and the result

Prio 1;

BVD and PD (or Design Type)

Prio 2;

(PD and Box-width and Box-height) and [Shape-tracer-data (or Tracer-model)]

or [Shape-id and [orderoption-5 or orderoption-6)]