Integration FAQ

GS1 Finland gathers frequently asked questions about integrations here. This page is aimed mainly towards technical personel. 

Terminology

The GDSN (Global Data Synchronization Network) is an Internet-based, interconnected network of interoperable data pools and a Global Registry, the GS1 Global Registry®, that enables companies around the world to exchange standardized and synchronized supply chain data with their trading partners. For more information see

Attributes

A piece of information reflecting a characteristic related to an identification number or data field (e.g. an expiration date or a product description related to a GTIN).

Attributes used in Finland can be found from the  Synkka Item Information Profile 3.1 document.

Legislation and procedures vary from country to country, creating the need for country-specific product information profiles. Trade item information always includes both the GDSN core and country-specific extensions. In GDSN standard the solution for these situations is A/VP (Attribute/Value Pair) Extension. It is a standard method for the transmission of attributes out of GDSN core.

A standard method for the transmission of new attributes and their values in XML consisting of a single schema “template” of data structures which does not need to change with the addition of attributes.

Suppliers and other sending partners will use the A/VPs to include high priority attributes in transmitted XML documents immediately upon GDD Fast Track Attribute approval or as non-standard Extended Attributes. Recipient data pools and trading partners may pull expected attribute names and their value pairs from the GDD and use immediately.

Code Lists & Validation Rules

Code lists are the standardized lists of values allowed at the given location of the message.

You can find all the code lists here ( FI) and here ( EN)

Agreed upon rules used to validate, authenticate or prove the conformance of routines performed in the GDSN. There may also be country-specific validation rules that are valid in a specific target market only.

Validation rules used in Finland can be found from the  Synkka Item Information Profile 3.1 document.

The max. length depends on the code list because some of them consist both code and the description of the code. GS1 FI recommends that receivers prepare to accept up to 5000 digits.

Product information must pass two kinds of validation before publication. GDSN rules are standardized and common to all data pools in various countries. The Finnish market has country-specific attributes which requires Finland specific validation rules. These validations must be passed as well before the product information can be published.

Connectivity

AS2 is the preferred connectivity type with Synkka Product. AS2 (Applicability Statement 2) Transports business-critical data over the Internet via HTTP (Hypertext Transfer Protocol) or HTTP/S (Secure HTTP). AS2 provides additional security protection as well as responding with a message letting the sender know that the data was received.

  • AS2 guarantees the PAIN (privacy, authentication, integrity, non repudiation) of the information
    • Privacy: Only the sender and recipient have access to the message content.
    • Authentication: The mediators (Sender, Recipient and intermediaries) have the mechanisms to prove their identity.
    • Integrity: It guarantees that the data has not been modified since generated by the sender.
    • Non repudiation: Guarantees that the recipient does not reject the message and that the sender does not deny it sent it.

If you want to use an FTP connection for message traffic with Synkka Product, you must use your own FTP server. In this model, Synkka Product regularly visits your server to query changes. The recommended retrieval frequency is once per 30 to 60 minutes. You can use either FTP or SFTP connectivity.

It makes it more difficult to investigate problems. In the FTP model, there are no confirmation messages for sent data, which makes it more difficult to confirm whether the data has actually been sent or received.

Integration can be built flexibly at any time. However, during holiday seasons, there may be less support available for testing connections and integration.

Message choreography in GDSN standard

The schemas are downloaded from the GDSN standards site.

For more information, see   GDSN XML Business Message Standards (BMS)

Version 3.1 includes the following schemas:

    • AlcoholInformationModule.xsd
    • AllergenInformationModule.xsd
    • BatteryInformationModule.xsd
    • CertificationInformationModule.xsd
    • ConsumerInstructionsModule.xsd
    • DairyFishMeatPoultryItemModule.xsd
    • DangerousSubstanceInformationModule.xsd
    • DeliveryPurchasingInformationModule.xsd
    • DietInformationModule.xsd
    • DutyFeeTaxInformationModule.xsd
    • FarmingAndProcessingInformationModule.xsd
    • FoodAndBeverageIngredientModule.xsd
    • FoodAndBeveragePreparationServingModule.xsd,
    • FoodAndBeveragePropertiesInformationModule.xsd
    • GdsnCommon.xsd
    • HealthRelatedInformationModule.xsd
    • MarketingInformationModule.xsd
    • NonGTINLogisticsUnitInformationModule.xsd
    • NutritionalInformationModule.xsd
    • PackagingInformationModule.xsd
    • PackagingMarkingModule.xsd
    • PlaceOfItemActivityModule.xsd
    • PriceSynchronisationDocument.xsd
    • ProductCharacteristicsModule.xsd
    • RegulatedTradeItemModule.xsd
    • SafetyDataSheetModule.xsd
    • SalesInformationModule.xsd
    • SharedCommon.xsd
    • SustainabilityModule.xsd
    • TradeItem.xsd
    • TradeItemDataCarrierAndIdentificationModule.xsd
    • TradeItemDescriptionModule.xsd
    • TradeItemDisposalInformationModule.xsd
    • TradeItemHandlingModule.xsd
    • TradeItemHierarchyModule.xsd
    • TradeItemLifespanModule.xsd
    • TradeItemMeasurementsModule.xsd
    • TradeItemSizeModule.xsd
    • TradeItemTemperatureInformationModule.xsd
    • TransportationHazardousClassificationModule.xsd
    • VariableTradeItemInformationModule.xsd
    • WarrantyInformationModule.xsd

For more information, see:   GDSN XML Business Message Standards 3.1 (BMS)

Synkka message choreography is based on the main GDSN XML messages, which comprises:

  • catalogueItemNotification (CIN): message containing the total package of information about an item, which includes the whole hierarchy of products
  • catalogueItemHierarchicalWithdrawal (CIHW): message used to cancel publication of an item by removing recipients from item’s access control list
  • catalogueItemSubscription (CIS): message used by Data Recipients to communicate the criteria for Trade Item information synchronization
  • catalogueItemConfirmation (CIC): Report sent to the supplier containing a summary of possible validation errors in previously sent CIN

Every XML message must contain a Standard Business Document Header, which includes the information of the sender and the recipient and indicates the message type.

CIN is a message containing all the attributes (trade item information) given for the item. Attributes without values will not be included into the message.

  • ADD: to add new items to the data pool
  • CHANGE_BY_REFRESH: to update the item information, if allowed by GTIN allocation rules
  • CORRECT: to correct mistakes in the information, normally not allowed by the GTIN allocation rules

When a supplier wants to stop the publication of an item hierarchy, it can be done by sending a Catalogue Item Hierarchical Withdrawal message to Synkka data pool. In release 2.8 this was handled by sending a CIN with the document command header DELETE to Synkka.

The GTIN to be used in the message is the top level GTIN of the hierarchy. The difference between the old and the new message is that the Catalogue Item Hierarchical Withdrawal -message does not contain any item information apart from the GTIN of the item.

When/if the only data recipient GLN assigned for the item is withdrawn the item must be published again. This can be done by sending a CIN-message with a document command header CHANGE_BY_REFRESH  and without giving any data recipients on the file.

A CIC message is a message sent in response to a CIN message by Synkka. It indicates the status of the trade item after it has been checked against country-specific validation rules. The message status can be “Review” or ”Accept”. The Synkka sends a CIC message with the status ”Review” if the CIN has not yet passed the country-specific validation (Synkka validation rules). The message will include a description of the error, among other information. The CIC is sent with the status ”Accept” if the CIN passed the validation.​

CIS is a trade item information request message, which recipients use to find suitable trade items for their selection in Synkka. Requests can also be made using the user interface. Request criteria include: GTIN code, GLN number, GPC classification and Target Market. If a CIS message is invalid, the sender will receive a GS1 Response “Rejected” report specifying the error, just like with CIN messages. Once these have been passed, Synkka sends a GS1 Response “Accepted” report in version 3.1 and saves the request.

  • ADD: to create a new Subscription; Subscription unicity is checked
  • DELETE: to delete an existent subscription
  • CHANGE_BY_REFRESH: to update the subscription information (in version 3.1)

Publication (Data Supplier)

  • When changes in the product information are given a new effective date
  • Product information and the basic characteristics of the product change notably
    • Supplier's additional trade item identification changes
    • Seasonal availability is updated
  • Changes should not be so significant they require a GTIN change​
  • Error in product information
    • Typographical error in product name
    • False information e.g. wrong nutrition fact
    • Missing information e.g. no nutrition facts
  • Effective date must be set to the date when corrections are going to be published
    • If item's effective date​ is set in the future the corrected version should have the same effective date. Otherwise a new version of the item will be created.
  • Product characteristics will not change​

Every message may include only one type of document command headers (ADD, CORRECT, CHANGE_BY_REFRESH and WITHDRAW). So in this case, the supplier should cover the changes with CORRECT, for both of the items.

There is no option to just simply remove an item from the data pool. To perform this operation, items need to be cancelled or discontinued first.

The supplier must define End availability date time and Cancel Date or Discontinue Date to cancel or discontinue an item. When these dates have passed, the item is Cancelled/Discontinued.

Deletes are not synchronized across data pools.

The data pool may remove an item that has been Cancelled or Discontinued for a period described in the EAN.UCC General Specification (after 48 months. 30 months for cloths sector).

In such cases, Synkka will send a new message of the entire hierarchy, with the piece of information removed. The message will not contain a notice that a specific piece of information has been removed.

Every product with its hierarchies is a separate message.

As long as all products are part of the same hierarchy.

Assortments were their own hierarchy levels in WS1 Sinfos and were presented in the same way as the base items. In turn, assortments are based to the same level as the dispatch units in Synkka. The base items which are part of the assortment are then linked to the assortment. For example, a consumer assortment (e.g. biscuit assortment) is based on the dispatch level and all of the items included in the assortment are based below that as base items.

It is possible to enter pallets without GTIN codes into Synkka, but GS1 Finland recommends using pallets with GTIN codes.

If the recipient has an active subscription in place, a new CIN message will be delivered each time subscribed item is changed. Synkka will send a new message of the entire hierarchy. If some information has been removed, a message with that particular piece of information removed is sent. However, the message will not point out what piece of information has been removed.

Subscription (Data Recipients)

The subscription criteria used is Target Market, GLN number, GPC classification and GTIN code. It is recommended to create subscriptions using supplier GLN for subscription criteria.

Responses to subscriptions will be sent on the same day, usually within 5-20 minutes from the time subscription was created. 

No. In such cases, Synkka will send a new message of the entire hierarchy, with the piece of information removed. The message will not contain a notice that a specific piece of information has been removed.

Only visible versions of items will be delivered to the recipients. This means even future versions can be sent if the supplier has set the item information publication date to take place before the effective date.