Technical Blueprint version 10
|
|  Yüklə 0.54 Mb.
|
4.2Distribution techniqueWith respect to the code list distribution technique, the following principles apply: 4.2.1File formatThe code list files will be available as CSV files, compressed in .zip format, using:
The files will be sorted on primary key. If so desired by the users, the distribution agent may offer the files in other formats, such as HTML, EDI, XML, XLS or any other. It’s also conceivable that FlorEcom will provide a (web)service, providing update detection on behalf of the users, so as to minimize data traffic over the network. In the event, this service will be elaborated by FlorEcom later. 4.2.2Character setSince the NAME code list will contain translations in languages that may use special (diacritic) characters, the Linnaeus code lists will support the UTF-8 character set (a subset of ISO/IEC 10646 Unicode). It will be up to those processing applications of the business partners, that do not support these characters, to replace special characters by appropriate dummies. In addition, the following rules/guidelines apply: No semicolons in fields To avoid possible conflicts with field separators, no code list field may contain a semicolon; the code list agent will see to this when producing the lists. Characters in EDI messages For the FlorEcom EDI messages (type EDIFACT), the current, limited UNOA and UNOB character sets will remain in place. Since EDI messages usually contain just codes and no descriptions or text, this restriction does not entail any functional limitation. Special characters in product names Some applications in the supply chain, like most auction clocks, are unable to display diacritic characters. This implies that product names with special characters may not be correctly displayable on a clock front. VKC (a plant registration authority) has rules allowing a limited set of diacritic characters, meaning that plant names with special characters may occur. Characters in codes The characters in feature tupe, feature type value and presentation abbriviations (in name) are limited to capitals, numbers and blanks. 4.2.3Distribution channelThe code list responsible agents will put their data in the appropriate directories on the FlorEcom server using the FTP protocol. Thence, the lists will be made available to the FlorEcom business partners in two ways:
The following applies with regards to: Security The Linnaeus code lists are of a (semi) public nature. To keep some control over the distribution platform’s payload and performance, the code list will be made available to users with a login-ID and password only. User name and password will not be exchanged in an encrypted fashion. Further details about the distribution technique will be conveyed by the distribution agent. 5.Linnaeus in EDI messagesThis chapter will deal with the impact of introducing the Linnaeus code system on the contents and structure of the EDIFACT messages applied in the floricultural industry. 5.1Mapping the Linnaeus technical data model on EDI messagesThe technical data model of the Linnaeus code system defines the following entity types related to the data exchange about floricultural lots. 5.1.1LotDefinition: A lot is a number of products having exactly the same features on the level of the sales unit, which are being marketed as a whole, on one specific place and one specific point in time, the legal ownership of which rests with one and only one supply chain partner. Relationships: Lot has the following relationships:
Mapping: In an EDI message, a lot is mapped on the LIN group. 5.1.2Base productDefinition: A base product is a lot’s primary product. Relationships: Base product has the following relationships:
Mapping: In an EDI message, the base product is specified in the LIN main line. 5.1.3PartDefinition: A part is a product which is a component of, or an accessory to a base product. Relationships: Part has the following relationships:
Mapping: In an EDI message, a part is specified in the LIN sub line. For further explanation of the notions ‘base product’ and ‘part’, see § 3.5 and 3.6 van Conceptual Blueprint (in Dutch). 5.1.4Lot featureDefinition: A lot feature is a feature of a base product or of a part of a lot, expressed in terms of the value of a feature type. Relationships: Lot feature has the following relationships:
Example: Examples of lot features are:
(phytosanitary feature: 100% free of Japanese rust) Mapping: In an EDI message, lot features will be specified in the LIN.CCI-CAV group; feature type in LIN.CCI and feature value in LIN.CAV. 5.1.5Photo referenceDefinition: A photo reference is the identification of a digital image belonging to a certain lot. Relationships: Photo reference has the following relationships:
Mapping: In an EDI message, photo references are (possibly repeatedly) specified in a LIN.RFF segment. 5.2Extension of lot featuresOne of the most obvious consequences of introducing Linnaeus will be a considerable increase of the number of lot features. In the FlorEcom messages these features will be specified in the CCI-CAV group. The number of occurrences of that group is currently limited to 99. In some messages, notably Ediflower EAB and EKT, lot features are not specified in CCI-CAV but in the IMD segment, which may occur maximum 99 times. The ‘proof of concept’ by the Linnaeus project group has demonstrated that, in actual practice, a number of 20 lot features is quite realistic. 5.3Harmonisation of the EDI messagesThe final elaboration of below recommendations with regards to the harmonisation of floricultural EDI messages will be FlorEcom’s responsibility. 5.3.1Uniform specification of lot featuresIn the interest of a uniform handling of lot features by processing applications, it is important that all EDI messages deal with features in a similar fashion. 5.3.2Uniform field formatsIn view of the key role of identifiers in the processing of EDI messages, precise definitions of identifier field formats are highly important. That’s why it is proposed that identifiers within the context of Linnaeus and FlorEcom are uniformly defined as numeric fields of variable length (N..n). Exception to this rule are the following identifiers:
In numeric fields, heading zero’s are redundant; in EDI message exchange such zero’s will be eliminated by standard Edifact translators. Likewise, such translators will remove possible trailing spaces in alphanumeric fields. 5.3.3Extension of the VBN product codeThe extension of the VBN product code from 5 to 7 digits calls for a change of the LIN 7140 data-element format from AN..5 to N..7 in all existing FlorEcom messages. 5.4Specification of composite lotsThe conceptual blueprint of the Linnaeus code system acknowledges the benefits of supporting composite lots. It’s description of how composite lots are specified is largely based on the current implementation of composites in the existing FlorEcom messages, only to propose a some minor changes to counter a few sticking points in the present specification. If, when and to what extend the proposed specification of composite lots will be adopted as a standard within the industry, is still to be decided. If so decided, however, it is evident that this will result in changes of the current FlorEcom convention manual, notably on the following counts:
5.4.1Definitions of conceptsThe current FlorEcom convention manual employs the following notions related to the composite lot phenomenon:
In future releases of the FlorEcom messages, the above notions will be replaced by:
5.4.2Dealing with nested compositesThe current FlorEcom messages allow composite products to be part of a composite themselves. Such multiple nesting has proven to complicate displaying composite products in most environments. In the newly proposed setup, composites may only act as base products, never as a part of another composite. This implies that parts of composite products (like mixed trolleys), may only be specified at the lowest level (of individual plant or possibly hardware). The drawback of this approach, being the inability to establish whether the packages on the trolley are composite items themselves and how they are composed, is resolved by specifying feature values of type S26 (mixed per trolley), S27 (mixed per shelf) and/or S28 (mixed per package). To indicate how the products are mixed inside a package, it is proposed to introduce a separate feature type ‘package sorting’ with values such as ‘sorted per row’, ‘diagonally sorted’ or ‘randomly sorted’. 5.4.3Dealing with hardwareThe current FlorEcom convention manual is unclear as to how hardware parts of composite product lots are specified. On the one hand, hardware may be specified using S61 feature type values. On the other, the convention allows for hardware to be indicated in sub lines, in which case specificity is severely limited by the small number of available VBN code for hardware (codes ‘2001’ and ‘1999’ only). The new approach assumes that VBN codes will be assigned to a limited number of about 40 hardware categories. Hardware parts will henceforth be specified using the appropriate VBN code in the sub line LIN segment rather than through S61 feature type values in a CCI-CAV group2. 5.4.4Pricing of compositesCurrently, partly due to the ambiguity in specifying parts mentioned above, the FlorEcom messages fail to be fully clear about the exact price of a composite item. The proposed new convention avoids this ambiguity by applying the following rules:
5.4.5Ordering partsAt present, FlorEcom allows buyers to specify the quantities and features of composite parts as they please. This has been causing misinterpretation and potential disruptions in automatic transaction handling. The new Linnaeus approach will avoid these problems by applying the following rules:
5.4.6Base product and parts indicatorsIn the current FlorEcom messages the type of a composite part is indicated by means of a so called sub line indicator (‘1’ for ‘part’ and ‘2’ for ‘accessory’). An indicator for base products does not currently exist. The new implementation of composite lot products in the FlorEcom messages will support sub line indicators reflecting the revised definitions as discussed in § 5.4.1:
In order to explicitly (but in fact redundantly) indicate that a LIN-group pertains to a base product or a part, it is proposed to require the LIN data-element 1222: configuration level, to be filled with the following mandatory values:
5.4.7LIN-group structure alignmentThe present FlorEcom convention manual discerns different types of LIN-group structures: for base products, accessories and parts. These different structures complicate the process of testing and certifying by FlorEcom. Moreover, in practice the structural differences between base products and parts are small. That’s why it is proposed to iron out the differences between base line and sub line structures in the FlorEcom message and make these uniform instead. Practically this will come down to defining some currently mandatory segments within the LIN-group as conditional in future versions. 6.Implementation suggestions and recommendationsThis chapter will include suggestions and recommendations with respect to the implementation of the Linnaeus system in business applications of the involved supply chain partners. 6.1Removed6.2Checking lot specification rules and constraintsThe floricultural sector is highly attached to a strict observance of regulations regarding lot specification. The business partners’ applications may play an important role in enforcing these regulations, notably when:
Based on the contents of the regulatory feature type code list for a particular lot product, the application could:
These concrete conditions are included in the paper version of the product specifications. It’s up to the developers of business applications to build in these conditions into their applications to be called and evaluated in case of conditional feature types. 6.3Storing and displaying multiple lot featuresInasmuch business applications still have lot features implemented as fixed attributes, the extension of the potential number of lot features will entail the introduction of a new and distinct ‘lot feature’ table, reflecting a 1-to-many relationship between lot and features. Whenever lot data is shown on a computer screen, the obvious solution would seem to display the mandatory lot features in a limited number of fixed fields, while the other features are presented on demand by means of an interactively callable pop-up window. 6.4Storing and displaying composite lots.The introduction of composite lots, if and when decided upon, will leave the existing lot data structures within an application basically untouched. The current lot data matches the new base product data; both are captured in a FlorEcom message base line. Component parts are likely to be stored in a newly introduced ‘parts’ table, implementing a 1-to-many relationship between lot and parts. The parts data structure resembles the lot table in its being identified by a VBN code and further specified by an arbitrary number of features. Just like lot base product features, the specification of part features is governed by the contents of the regulatory feature type table. An obvious approach to displaying composites on a computer screen is to fit such lot products with an composite indicator, allowing the user to interactively call a pop-up window showing its component parts. 1 The format of most feature values currently is, and will remain, AN3. The precise definition of these values will be decided upon by VBN, taking as the rule that numeric feature values will be filled out to precisely 3 position using preceding zeroes if needed. Exception to this rule are values of feature types S69 and S98 whose format will remain AN2 2 Some Edifact messages do not yet support CCI-CAV for specifying lot features, in which case IMD is employed 3 Whether or not the occurrence of disallowed feature types can indeed be checked, will depend on a still to be taken decision about the inclusion of ‘allowed’ feature types.. |