GDSN_2_7

Hướng dẫn hoạt động GDSN Phiên bản GDSN 2.7

Xuất bản lần 1, đã được duyệt, 9-2011

GDSN Operations Manual

GDSN Version 2.7

Issue 1, Approved, Sep-2011

GDSN Hướng dẫn sử dụng GDSN phiên bản 2.7

All contents copyright © GS1

1

Tóm tắt

Mục tài liệu Giá trị hiện thời

Tiêu đề tài liệu GDSN Hướng dẫn thực thi GDSN phiên bản 2.7

Ngày sửa chữa sau cùng O9-2011

Phát hành tài liệu Lần 1

Trạng thái tài liệu Được phê chuẩn

Mô tả tài liệu Đây là Tài liệu Hướng dẫn thực thi của GDSN cho GDSN phiên bản 2.7

Người cộng tác

Tên Tổ chức

Tổ chức Tư vấn Công nghệ và điều hành GDSN

GS1

Các phiên bản

Lần phát hành Tóm tắt những thay đổi

01-2005

• Bổ sung mục 2.2.3.1, có ví dụ kèm theo.

• Viết lại các mục 2.2.2 và 2.2.5 để nhất quán chỉ ra Lệnh Xóa (delete) hoạt động trên một con trỏ và không

phải trên một tài liệu.

• Xóa trong mục 4.2.3 từ diễn đạt rằng RFCIN tạo ra một hội viên GS1 GR.

• Hiệu chỉnh mục 4.2.4 thành tình trạng cập nhật chỉ sảy ra nếu một ấn phẩm tương ứng với 1 hội viên mới.

04-2005 • Cập nhật chương SBDH với nội dung đã được phê duyệt; bổ sung mã thông báo (MessageID) và chủ sở hữu nội

dung.

• Làm rõ nội dung.

03-2006

• Loại bỏ các tham khảo tới phong bao thành SBDH

• Loại bỏ hầu hết các tham khảo tới mục 1.3.2

• Loại bỏ các tham khảo tới AS2 và các header của ebMS

• Loại bỏ các mục 2.4, 3.1.1.1, 4.2.1, 4.2.2, 4.2.3, 4.2.4, 4.4.1, 5.3.1

• Xóa bỏ Hình vẽ 7 và danh sách sau hình vẽ này từ mục 5.2

04-2006

• Xóa bỏ Bảng 2

• Hiệu chỉnh các URLs cho SBDH1.3

• Bổ sung các URLs cho các giản đồ XML và giản đồ tiêu chuẩn (cả bản thử (Beta) và thành phẩm

• Thay EAN.UCC bằng GS1 trong phần tường thuật của tài liệu

• Bổ sung Chương AVPs

05-2006

• Thay thế biểu tượng (logo) EAN.UCC bằng biểu tượng GDSN

• Xắp xếp lại cấu trúc của tài liệu và làm sáng rõ hơn về mặt nội dung

• Loại bỏ nội dung có liên quan đến GSMP XML mà hiện đang tồn tại trên trang website của GSMP

• Loại bỏ chương AVPs như là nó sẽ hiện hữu trên trang website

• Thay đổi giới hạn của các giao dịch trên thông báo từ 10 thành 100 và hợp nhất nội dung của nó với các hạn chế

khác trong cấu trúc thông báo GDSN

• Bổ sung khai báo về kết xuất nhóm (Party Dump)

• Thay thế biểu tượng EAN.UCC bằng biểu tượng GDSN

• Bổ sung mục Quản trị thay đổi (Change Management)

• Bổ sung nội dung cho mục Các đặc trưng GDSN

• Bổ sung mục On-boarding



2

Lần phát hành Tóm tắt những thay đổi

07-2006

• Bổ sung tham khảo cho Thuật ngữ GS1

• Loại bỏ mục rỗng “WebSite GDSN” khi nó đã được nhắc đến trong mục 2.3

• Bổ sung mục “Tài liệu ví dụ XML GDSN” mà minh họa cho cách sử dụng giản đồ định vị

• Cập nhật chương SBDH; bao gồm các nguyên tắc rõ ràng hơn và ví dụ riêng biệt thành 2 loại: yêu cầu và phản hồi

• Cập nhật “Phản hồi trong chương GDSN”

• Đổi tên và cập nhật chương “Định danh thông báo trong GDSN”; bổ sung mục con trong Chỉ số thực thể

• Bổ sung mục trong TMSV

15-09-2006

• Mã hóa các phần chia nhỏ của thị trường mục tiêu

• Xác nhận giản đồ XML

• Điều chỉnh định dạng (thụt lề) trong mục 5.3.1.1 đối với những thông tin tương quan và các yếu tố dịch vụ thương mại

• Thay đổi phiên bản của tài liệu về các quy tắc có hiệu lực

02-10-2006 • Thay đổi phiên bản của tài liệu về các quy tắc có hiệu lực

• Thay đổi nội dung có liên quan tới nhận dạng đối tượng

15-12-2006

• Điều chỉnh các tham khảo cần thiết để chỉ rõ các đồ tạo tác trong mục 2.1

• Bổ sung các quy tắc có liên quan tới các tiền tố của không gian tên

• Bổ sung quy tắc liên quan tới đáp ứng đơn ngược lại với đa đáp ứng

• Điều chỉnh tham khảo Hướng dẫn liên lạc truyền tải cho EDIINT AS1 và AS2 04-01-2007 • Điều chỉnh tham khảo: Hướng dẫn thực hành, các quy tắc hợp lệ và Hướng dẫn thực thi công nghệ BMS, XML

18-07-2011

• Viết lại Chương các tiêu chuẩn GDSN

• Điều chỉnh tham khảo cần thiết để chỉ rõ các đồ tạo tác trong mục 2.7 (và 2.7.3)

• Cập nhật chương Các thông báo tùy chọn, Các thuộc tính và các đuôi mở rộng

• Bổ sung Chương Duy trì tài liệu

• Bổ sung Chương dành cho các thuộc tính phản đối

• Bổ sung Chương Khắc phục thảm họa

• Bổ sung Chương Thực thi GPC 15-09-2011 • Tài liệu sau cùng

Không công nhận

Trong khi mọi nỗ lực để đảm bảo rằng các nguyên tắc được sử dụng trong các tiêu chuẩn GS1 trong tài liệu này là chính xác, GS1 và bất kỳ cá nhân hay tổ chức nào liên quan đến việc tạo lập tài liệu HEREBY STATE mà tài liệu này được cung cấp không được sự cho phép, nhằm mục đích riêng khác hoặc ngụ ý khác, về tính chính xác hoặc tính hợp lệ, VÀ HEREBY KHÔNG CÔNG NHẬN bất kỳ trách nhiệm pháp lý nào, trực tiếp hoặc gián tiếp cho các thiệt hại hoặc tổn thất liên quan đến việc sử dụng tài liệu này. Tài liệu này có thể sửa đổi, là đối tượng để phát triển về mặt công nghệ, thay đổi các tiêu chuẩn, hoặc sửa đổi theo nhu cầu pháp lý mới. Một số tên sản phẩm và tên các công ty đề cập trong tài liệu này có thể là tên thương mại và/hoặc được đăng ký tên thương mại của công ty tương ứng.



3

1. Mở đầu

Quy trình quản trị các tiêu chuẩn toàn cầu (GSMP) là quy trình toàn cầu được GS1 thành lập để duy trì và phát triển các Tiêu chuẩn toàn cầu cho hệ thống GS1. Tiêu chuẩn toàn cầu bao gồm: Đặc tả tổng quát GS1, EANCOM đối với giao diện dữ liệu điện tử và các tiêu chuẩn thông báo thương mại (BMS) đối với XML được sử dụng trong GDSN. Các tiêu chuẩn này dựa trên các nhu cầu trong thương mại và các yêu cầu kỹ thuật của các thành viên sử dụng quy trình đồng thuận toàn cầu để phát triển các tiêu chuẩn trong chuỗi cung ứng.

Hướng dẫn thực thi GS1 GDSN (Mạng lưới đồng bộ hóa dữ liệu toàn cầu) là một sách hướng dẫn để thực thi trong Mạng lưới. Nó là một “tài liệu sống” mà được cập nhật định kỳ dựa trên nền tảng các yêu cầu. Tài liệu hướng dẫn thực thi này nên được tham khảo lâu dài cùng với các Tài liệu phân tích các yêu cầu trong thương mại (BRAD) và Các tiêu chuẩn thông báo thương mại (BMS) được Quy trình quản trị các tiêu chuẩn toàn cầu (GSMP) của GS1 thành lập. Các tài liệu BRAD và BMS là các tài liệu quy chuẩn – chúng định rõ các tiêu chuẩn; thực thi các chuẩn như thế nào được mô tả trong Hướng dẫn thực thi. Các tác giả và các nhà biên tập sách Hướng dẫn thực thi chịu trách nhiệm để đảm bảo rằng không có sự trái ngược nhau giữa các tài liệu quy chuẩn và sách hướng dẫn này. Do các tiêu chuẩn trong GDSN là động và kết quả liên tiếp của các bài học bổ sung trong những lần sửa đổi các tiêu chuẩn nên sẽ nảy sinh sự khác nhau giữa các tiêu chuẩn trong các tài liệu khác nhau và các bài học được tôi luyện thông qua thực tế. Các bài học thực tế có thể áp dụng được có trong Sách hướng dẫn thực thi (Operations Manual) sẽ được Tổ chức GDSN quyết định chọn lựa những điểm mấu chốt tham khảo trước khi xây dựng thành tiêu chuẩn trong BMS.

1.1. Mục đích của tài liệu này

Mục đích của tài liệu này là giải thích cách sử dụng các tiêu chuẩn GS1 trong Mạng lưới đồng bộ hóa dữ liệu toàn cầu (GDSN). Nó trả lời cho câu hỏi - “Tôi có cần phải xây dựng một tiêu chuẩn thực thi dễ dàng”. Các tài liệu khác của GDNS cung cấp một cái nhìn khái quát của GDSN hoặc các thủ tục kinh doanh đằng sau GDSN và tài liệu này cung cấp một Hướng dẫn thực thi để giúp cho người sử dụng của GDSN và cộng đồng những người thực hiện theo. Nó được bổ sung thêm bởi các tài liệu thủ tục kinh doanh GDSN cung cấp chi tiết về việc thực thi GDSN như thế nào. Nội dung của nó sẽ được mở rộng và sẽ thay đổi theo nhu cầu của người sử dụng. Tài liệu này và các bản cập nhật của tài liệu này sẽ có trên địa chỉ http://www.gs1.org/services/gsmp/kc/gdsn/ và có thể được tải về từ địa chỉ này.

1.2. Audience

Tài liệu này khuyến khích sử dụng để thực thi Mạng lưới đồng bộ hóa dữ liệu toàn cầu (Đăng ký toàn cầu GS1, các dữ liệu dùng chung GDSN và các đối tác thương mại GDSN). Tài liệu này dành cho các nhà kinh doanh và các nhà phát triển GDSN. Họ sẽ thực thi GDSN dựa vào hướng dẫn thực thi và các tiêu chuẩn đã được công bố trong BMS. Trong hầu hết các trường hợp, họ có thể không tham dự các hội nghị của GDSN. Thông tin trong tài liệu này được sắp xếp theo cách sao cho đầy đủ ý nghĩa nhất với họ. Thêm vào đó, tài liệu này cũng dành cho những thành viên tham gia vào quá trình phát triển các tiêu chuẩn của GDSN.

1.3. Trọng tâm kiến thức GDSN

Đường dẫn sau đây giúp bạn đọc truy cập tới các tài liệu có trong Hình vẽ 1.1, sẽ cung cấp thông tin cần thiết bổ sung cũng như thông tin liên quan khác: http://www.gs1.org/gsmp/kc/gdsn.

http://www.gs1.org/services/gsmp/kc/gdsn/

http://www.gs1.org/gsmp/kc/gdsn



4

Hình vẽ 1.1: Trọng tâm kiến thức GDSN

2. Các tiêu chuẩn GDSN

Các đối tác thương mại GDSN, các dữ liệu dùng chung GDSN và Đăng ký toàn cầu GS1 tương tác với nhau thông qua các thông báo có giao diện tiêu chuẩn. Các thông báo giao diện tiêu chuẩn xác định này (The defined standard interface messages), các mô hình lớp ngôn ngữ thống nhất (Uniform Model Language (UML) class models) của chúng và các lựa chọn chức năng sử dụng (hàm) (use cases) có thể tham khảo trong các tài liệu Chuẩn thông báo kinh doanh (BMS). Các biểu đồ lớp được chuyển đổi vào các lược đồ trong Ngôn ngữ hình học XML W3C. Mục đích giao dịch này là duy trì từ BRAD tới BMS thông qua sự nhận thức rõ lược đồ, dù cho các yêu cầu về cú pháp XML, hàm giao dịch chéo đồng nhất và các thành phần có thể sử dụng nhiều lần sẽ giảm thiểu sự sai lệch giữa tài liệu BMS và lược đồ. Một sản phẩm thương mại là bất kỳ sản phẩm thương mại nào (thương phẩm hoặc dịch vụ) mà con người có thể có nhu cầu lấy được những thông tin được xác định trước. Đó có thể là giá, đơn đặt mua hàng, hoặc hoá đơn thanh toán tại bất kỳ đâu trong bất kỳ chuỗi cung ứng nào đó. GTIN là một trong những chìa khóa của hệ thống GS1. Các sản phẩm thương mại được phân định với một GTIN.Thuật ngữ "sản phẩm thương mại" có thể tương ứng với bất kỳ mức độ ngăn chặn sản phẩm nào. Có sự khác biệt giữa một “sản phẩm thương mại” và một "sản phẩm chỉ có trên Catalogue". Sản phẩm thương mại bao gồm sự mô tả về sản phẩm thương mại cũng như có thể có hoặc không cấu trúc phân cấp. Chìa khóa của sản phẩm thương mại là 1 GTIN. Sản phẩm thương mại được đăng ký bởi chủ sở hữu GTIN và cho phép chủ sở hữu GTIN xác định các thuộc tính không thể thay đổi. Các sản phẩm chỉ có trên Catalogue chỉ có mô tả về cách sử dụng sản phẩm, hay nói cách khác là nội dung của sản phẩm. Một sản phẩm chỉ có trên Catalogue được xác định duy nhất trong Đăng ký Toàn cầu GS1 bằng cách kết hợp Mã số Phân định Thương mại Toàn cầu của sản phẩm (GTIN), Mã số Địa chỉ Toàn cầu của Nhà cung cấp Thông tin (GLN), và Thị trường Mục tiêu. Nó được đăng ký bởi Nhà cung cấp Thông tin, người có thể hoặc không tương đương với Chủ sở hữu Thương hiệu GTIN, tạo điều kiện cho Nhà cung cấp Thông tin linh hoạt Nó được đăng ký bởi các nhà cung cấp thông tin, người có thể có hoặc không tương đương với các chủ sở hữu thương hiệu GTIN và cho phép sự linh hoạt cho Nhà cung cấp thông tin để cho phép các dữ liệu trên của GLN và / hoặc thị trường mục tiêu khác nhau. Thị trường mục tiêu (TM) là một 3-chữ số mã số chỉ cấp quốc gia hoặc cao hơn định nghĩa địa lý, trong đó các nhà cung cấp thông tin sẽ tạo các mục có sẵn cho người mua. Chỉ số này không chi phối nơi mà một nhà mua hàng có thể bán lại



5

món hàng cho người tiêu dùng. Mã quốc gia thị trường mục tiêu được lấy từ danh sách 3166-1 của tiêu chuẩn ISO. Thị trường mục tiêu cũng có thể bao gồm mã thứ cấp. Mã thứ cấp thị trường mục tiêu được lấy từ danh sách 3166-1 của tiêu chuẩn ISO. Mỗi mặt hàng thương mại được xem như một mặt hàng độc lập, tách rời trong Đăng ký Toàn cầu GS1. (Để biết thêm chi tiết mời xem thêm tại BMS.)

2.1. Luồng dữ liệu Đồng bộ hóa dữ liệu toàn cầu (GDSN)

Hình vẽ 2 mô tả luồng tổng thể của tất cả các thông điệp khác nhau trong GDSN theo các thực thể. Các thông điệp này có thể phụ thuộc khác nhau tùy vào người gửi và người nhận thông điệp đó. Một số thông điệp được thiết kế như là những thông điệp đa bước truyền và có thể lưu thông qua các phần khác nhau của mạng internet.

Hình 2-1 Mô hình GDSN đầy đủFull

5 – Mặt hàng / Hàng đặt trước

Khớp với đăng ký toàn cầu

Yêu cầu Khai báo

Mặt hàng theo Catalog 1

Đăng ký Toàn cầu

2`

Yêu cầu Khai báo


Đăng ký Mặt hàng theo Catalog

6

4

Tiền đặt

Yêu cầu khai báo


Kho

Tiền đặt hàng theo

Catalog

hàng Theo Catalog

8

Kho DL 1

Khởi tạomặt hàng và cập nhật

DL nguồn

7

Khai báo mặt hàng theo Catalog

Xác nhận mặt hàng theo Catalog

11

Người nhận Tiền Đặt hàng

3 Khai báo

Mặt hàng

Nguồn Dữ liệu

Công bố

Mặt hàng

Xác nhận Mặt hàng

10

9

Người nhận Dữ liệu

Xác nhận mặt hàng 12

Chú thích: Tất cả các thông điệp có 1 thông điệp phản hồi mặc định

1. Không yêu cầu phải thiết lập đồng bộ hóa Thông điệp RF CIN



2.1.1. Các thành phần của GDSN

Dưới đây là chức năng của các thành phần trong GDSN – Đăng ký toàn cầu, Nguồn dữ liệu, Nguồn dữ liệu dùng chung, Dữ liệu người nhận dùng chung và Người nhận dữ liệu:

Đăng ký toàn cầu GS1

- Cho phép đăng ký và phân tán thông tin của Thành viên tham gia, phân định các thành phần và vai trò - Cho phép đăng ký tất cả thông tin mặt hàng thông qua một tập nhỏ các tiêu chí

+ GTIN, GLN của Nhà cung cấp thông tin, Thị trường mục tiêu, và GPC - Các dịch vụ cung cấp xác thực để đảm bảo tính đơn nhất - Cho phép đăng ký đặt hàng tất cả các mặt hàng với một tập nhỏ các tiêu chí

+ GTIN, GLN của Nhà cung cấp thông tin, Thị trường mục tiêu, và GPC - Thực thi quá trình khớp đơn đặt hàng / mặt hàng tại lõi của hệ thống GDSN.

Nguồn dữ liệu

. Thường là một Nhà sản xuất / Nhà phân phối

. Duy trì thông tin hàng hóa được mong muốn trong GDSN

. Đăng ký thông tin mặt hàng thương mại trong Dữ liệu Dùng chung Ban đầu để sẽ được đăng ký với Đăng ký Toàn cầu và gửi một Dữ liệu Người nhận Dùng chung.

. Gửi thông tin mặt hàng thương mại ở bất kỳ định dạng nào đã thỏa thuận giữa Nguồn dữ liệu và Dữ liệu Dùng chung ban đầu

Dữ liệu dùng chung Ban đầu

. Xác nhận thông tin sản phẩm dựa vào các Quy tắc Hợp lệ GDSN (Bắt buộc)

. Nhận thông tin mặt hàng thương mại từ Nguồn dữ liệu sẽ được đăng ký

. Sử dụng các thông điệp XML chuẩn để đăng ký thông tin mặt hàng trong Đăng ký Toàn cầu

. Sử dụng các thông điệp XML chuẩn để trao đổi thông tin mặt hàng thương mại với Dữ liệu Người nhận Dùng chung (và Nguồn dữ liệu)

Người nhận dữ liệu

. Thường là một Bệnh viện tỉnh lẻ, Tổ chức mua hàng theo nhóm, Nhà phân phối hoặc bất kỳ Người dùng dữ liệu nào

. Tiền đặt hàng cho thông tin mặt hàng thương mại, gồm sự kết hợp của bất kỳ thông số nào sau đây:

- Mặt hàng (GTIN)

- Người tham gia (GLN)

- Thị trường mục tiêu

- Khối GPC

. Nhận được thông tin mặt hàng thương mại ở dạng thỏa thuận với Dữ liệu Người nhận Dùng chung

Dữ liệu người nhận dùng chung

. Có thể xác nhận thông tin mặt hàng dựa trên các Quy tắc có hiệu lực của GDSN (không bắt buộc)

. Nhận các đơn đặt hàng từ Người nhận dữ liệu của chính nó sử dụng các tiêu chí

. Đăng ký các đơn đặt hàng trong Đăng ký toàn cầu

. Nhận thông tin mặt hàng từ Dữ liệu Dùng chung Ban đầu, bao gồm cả thông tin mới và thông tin cập nhật

. Cung cấp thông tin mặt hàng thương mại từ Dữ liệu Dùng chung Ban đầu tới Người nhận dữ liệu.

Ý nghĩa của đám mây là: bên trong đám mây này tượng trưng cho phần “trong mạng lưới” của GDSN. Bên trong đám mây, tất cả các giao dịch bằng thông điệp được xác định hoàn toàn bởi các tiêu chuẩn của GDSN. Tất cả các Dữ liệu Dùng chung phải sử dụng cùng những thông điệp theo đúng phương thức. Bên ngoài mạng lưới (bên ngoài đám mây), cách thức mà các Dữ liệu Dùng chung giao thiệp với các đối tác thương mại của họ (các Nguồn Dữ liệu và các Người Nhận Dữ liệu) là tới các Dữ liệu Dùng chung. Tính linh hoạt này cho phép các Dữ liệu Dùng chung tạo ra các dịch vụ giá trị gia tăng cho các khách hàng của họ. Ví dụ, thông tin mặt hàng có thể chuyển tới các Dữ liệu Dùng chung dưới các định dạng bổ sung như các file excel, các file văn bản, các thông điệp Trao đổi Dữ liệu Điện tử (EDI) hiện có. Các Dữ liệu Dùng chung có thể chuyển đổi các định dạng này sang dạng các thông điệp XML (XML - Ngôn ngữ Đánh dấu Mở rộng) cơ bản và tiêu chuẩn để sử dụng trong mạng lưới và có thể chuyển đổi ngược lại khi các thông điệp đã được nhận qua mạng lưới.


Issue l, Approved, Sep-20ll All contents copyright © GS1

2.1.2. Cách sử dụng các thông điệp XML lược đồ cơ sở XSD

Tất cả các giao dịch trong mạng lưới trong nội bộ một Dữ liệu Dùng chung và từ Dữ liệu Dùng chung này tới Đăng ký Toàn cầu đòi hỏi việc sử dụng các thông điệp XML chuẩn GDSN. GDSN sử dụng một bộ cơ sở XSD được chuẩn hóa và các thông điệp XML. Hình 2-2 cho thấy bộ các chuẩn GDSN liên quan hiện tại

Hình 2-2: Các tiêu chuẩn GDSN

Đồng bộ hóa mặt hàng theo Catalog Đồng bộ hóa thành phần cơ bản

Cấp phép mặt hàng Thư viện chung GDSN

Đồng bộ hóa giá cả GDSN Mặt hàng thương mại GDSN

Mở rộng mặt hàng thương mại GDSN:

Đồ trang sức và thời trang

Hình ảnh trực quan có âm thanh liên kết giá trị thuộc tính (AVP)

Các thuộc tính của ứng viên mã vạch

Các trò chơi điện tử

FMCG

Thức ăn và đồ uống

Hardlines (hữu tuyến ?)

Chăm sóc sức khỏe

Các ấn phẩm phim ảnh

Các băng đĩa âm nhạc

Các đơn vị Logistic phi GTIN

Thiết bị văn phòng

Mặt hàng thương mại được quảng cáo

Tuân thủ quy định

Các đặc điểm kỹ thuật đặc trưng

Specific Technical Characteristics

Vật liệu nguy hiểm với nước Mỹ

US Hazmat (Hazardous Materials)

Tiêu chuẩn quan trọng nhất đối với GDSN là chuẩn “Đồng bộ hóa mặt hàng theo Catalog” - nghĩa là chuẩn này là chuẩn thực thi chính yếu trong GDSN. Mở rộng mặt hàng thương mại trong GDSN là phần mở rộng riêng biệt đối với mặt hàng thương mại có bổ sung thêm thông tin cụ thể đối với nhu cầu công nghiệp đặc thù hoặc nhu cầu kinh doanh.

Trong Quá trình đồng bộ hóa mặt hàng thương mại theo Catalog, có mặt những thông điệp chuẩn sau đây:

■ Xác nhận mặt hàng theo catalog

■ Khai báo mặt hàng theo catolog

■ Công bố mặt hàng theo catolog

■ Trả lời đăng ký mặt hàng theo catalog

■ Tiền đặt hàng theo catalog

■ Registry Catalogue Item Đăng ký mặt hàng theo catalog

■ Yêu cầu khai báo mặt hàng theo catalog

■ Trả lời EAN•UCC

■ Ngoại lệ GDSN

Tất cả các thông điệp được định rõ trong tiêu chuẩn và được tạo ra bằng cách sử dụng các mẫu của ngôn ngữ mô hình hóa thống nhất (UML). Các mẫu này sau đó được sử dụng trong việc tạo lập các thông điệp XML. Hình vẽ 2-3 minh họa cho thông điệp Đăng ký mặt hàng theo catalog.



Hình vẽ 2-3 Mẫu UML của Thông điệp Đăng ký mặt hàng theo catalog

2.1.3. Giao thức truyền thông

Tất cả các thông điệp truyền tải “trong mạng lưới” giữa các Dữ liệu Dùng chung với nhau hoặc giữa Dữ liệu Dùng chung và Tổ chức Đăng ký Toàn cầu được gửi thông qua internet sử dụng EDI trên internet, Giao thức truyền thông của Phần mềm kỹ thuật số 2 (EDIINT AS2). Giao thức này được sử dụng cho việc trao đổi thông tin trong một môi trường phân tán, phân quyền; được thiết kế và mã hóa bởi Nhóm đặc trách kỹ thuật internet (IETF). Trong phiên bản đầu tiên của nó, AS1, nó được sử dụng chủ yếu để truyền các thông điêp EDI sử dụng thư điện tử trên internet, sử dụng Giao thức truyền tải thư tín đơn giản(SMTP). AS2 sử dụng giao thức truyền dữ liệu siêu văn bản (HTTP) để xây dựng một kênh kết nối tới địa chỉ người nhận, thiết lập kết nối, sau đó gửi thông tin trong một môi trường an toàn đảm bảo đối với người gửi về việc đã gửi thư. Cách sử dụng các xác nhận này cũng được thực thi trong GDSN, như vậy chỉ những thực thể mà có liên kết với tổ chức Đăng ký Toàn cầu mới là các Dữ liệu Dùng chung được xác nhận bởi GDSN.

2.2. Phối hợp đồng bộ hóa cơ bản các bên tham gia

Quá trình đồng bộ hóa cơ bản các bên tham gia là 1 điều kiện tiên quyết bắt buộc đối với quá trình đồng bộ hóa các mặt hàng theo catalog và được sử dụng bởi tất cả các Dữ liệu Dùng chung để đăng ký thành viên (các GLN) trong Tổ chức Đăng ký toàn cầu. Trong Tổ chức Đăng ký toàn cầu , các bên tham gia được định danh bởi GLN riêng biệt, được đăng ký bởi một Dữ liệu Dùng chung. Các bên tham gia thương mại GDSN cần có thông tin dữ liệu của mình để tiến hành đồng bộ hóa dữ liệu. Mỗi bên tham gia phải đăng ký với Tổ chức Đăng ký toàn cầu để tham gia vào bất cứ chức năng GDSN nào, bao gồm việc đăng ký các mặt hàng hoặc đặt mua hàng. Tất cả các dữ liệu dùng chung (hoặc là gốc, hoặc là của người nhận) đều phải đăng ký thông tin tổ chức của mình với đại diện của các đối tác thương mại khác. Quá trình đăng ký này như sau:

■ Dữ liệu Dùng chung của Đối tác Thương mại chuyển giao thông tin tổ chức của mình tới Dữ liệu dùng chung theo định dạng phù hợp.

■ Dữ liệu Dùng chung sử dụng thông tin này và tạo lập thông điệp Đăng ký thành viên chuẩn như đã xác định trong quá trình Đăng ký cơ bản các bên tham gia. Thông điệp này phải thông qua mọi phê chuẩn thay cho việc đăng ký với các bên tham gia khác.

■ Tổ chức Đăng ký toàn cầu gửi trả lại một thông điệp “Trả lời Bên tham gia” (nếu như Bên tham gia đã đăng ký thành công) hoặc một “Thông điệp từ chối GDSN” (Nếu Bên tham gia chưa đăng ký

<<Trừu tượng>>

Tài liệu

(từ tài liệu)

Thông điệp này cần Thông tin

xác nhận mặt hàng theo catalog

Mã phân định thực thể

(từ Mã phân định thực

thể)

+ Phân định Đăng ký mặt hàng theo catalog

Dữ liệu Dùng chung Ban đầu : GLN

<<Gốc>>

Đăng ký mặt hàng theo catalog Trạng thái Đăng ký mặt hàng theo catalog

Trạng thái: Danh sách trạng thái Đăng ký mặt hàng theo catalog

Tham chiếu mặt hàng theo catalog

(từ Catalog mặt hàng chung)

Phân loại sản phẩm trong catalog

(từ Catalog mặt hàng chung)



thành công). Thông điệp từ chối cũng chứa cả những lỗi tìm thấy để cho thấy vì sao Bên tham gia không đăng ký được. Sau khi đăng ký thành công, Tổ chức Đăng ký Toàn cầu GS1 sẽ lưu trữ thông tin của Bên tham gia, bao gồm cả thông tin Dữ liệu Dùng chung, phân định Dữ liệu Dùng chung có nghĩa vụ về mặt pháp lý của Bên tham gia đó.

2.2.1. Kết xuất thành viên

Có một quá trình xử lý theo lô trong hệ thống Đăng ký Toàn cầu, chạy nền tảng hàng ngày để tạo ra 1 file có chứa mọi thông tin của tất cả các Bên tham gia trong Hệ thống Đăng ký Toàn cầu, bao gồm những thông tin như: GLN, tên thành viên, địa chỉ, tên giao dịch, quốc gia, mã quốc gia, ..v.v. File XML này của tất cả các thành viên GDSN được gửi cho tất cả các Dữ liệu Dùng chung được xác nhận trong GDSN để sử dụng trong quá trình đồng bộ hóa thông tin các thành viên tham gia GDSN.

2.3. Đồng bộ hóa các mặt hàng theo catalog và chức năng Đăng ký toàn cầu

2.3.1. Việc đăng ký các mặt hàng theo catalog (RCI)

Đăng ký mặt hàng theo catalog là thông điệp kinh doanh được sử dụng để đăng ký thông tin mặt hàng thương mại từ một Dữ liệu Dùng chung tới hệ thống Đăng ký Toàn cầu trong mạng lưới của GDSN. Quá trình này được minh họa trong Hình vẽ 2-4.

Hình vẽ 2-4 Quá trình đăng ký mặt hàng

2

Đăng ký mặt

hàng theo

catalog

Đăng ký

Toàn cầu

Kho DL

1 nguồn

Tạo mặt hàng

Và cập nhật

Nguồn

DL

1. Đầu tiên, một nguồn dữ liệu được tải đầy đủ chứa thông tin mặt hàng (mà có thể bao gồm các giá

trị cho nhiều trường thuộc tính mô tả cho mặt hàng thương mại mà các khách hàng của họ cần đến và tiến trình kinh doanh cũng sẽ sử dụng dữ liệu này).

2. Với những thông tin này, Dữ liệu Dùng chung Ban đầu hình thành nên thông điệp đăng ký mặt hàng theo catalog sử dụng thông tin chính sau:

a. GTIN

b. GLN của Nhà cung cấp thông tin

c. Thị trường mục tiêu của nơi được dự định sẽ bán GTIN

d. Mã Phân loại sản phẩm toàn cầu (GPC) mã Brick

- và -

e. Tình trạng và một số ngày tháng liên quan (ngày tạo lập, ngày bảo quản sau cùng)

f. Dữ liệu Dùng chung có tính pháp lý đối với Đối tác thương mại và các mặt hàng của mình



3. Thông tin này được đăng ký trên Tổ chức Đăng ký Toàn cầu nếu như được kiểm tra tính đơn nhất và được phê chuẩn

Thông điệp đăng ký mặt hàng theo catalog được tuân thủ hoàn toàn theo các tiêu chuẩn và mọi Dữ liệu Dùng chung phải sử dụng cùng những thông điệp và những phê chuẩn đang hiệu lực. Cách thức mà Nguồn dữ liệu tạo lập nên dữ liệu các mặt hàng trong Dữ liệu Dùng chung Ban đầu phụ thuộc vào thỏa thuận chung giữa các bên và việc chọn dữ liệu dùng chung của họ. Ví dụ, sử dụng một giao diện người dùng đồ họa là có thể để tạo lập và đăng ký thông tin. Điều này cũng có thể được thực hiện sử dụng các bộ thông điệp EDI hiện có mà không có liên quan gì đến GDSN.

Một khía cạnh quan trọng khác của quy trình GDSN là tại Dữ liệu Dùng chung Ban đầu, những mặt hàng mà chuẩn bị kết nối thường được sắp xếp trong hệ thống phân cấp sản phẩm. Đây là một cách thức cho biết các mặt hàng được đóng gói để chứa đựng mỗi cấp tiếp theo trong hệ thống phân cấp. Ví dụ như xét một lon soda. Trong chuỗi cung ứng, lon soda này thường được đóng gói 6 lon (gói 6 lon), đóng trong hộp gồm 4 x (gói 6 lon). Các hộp này có thể được đóng gói theo palet có 60 hộp. Đây là một ví dụ về hệ thống phân cấp mặt hàng. Cũng có thể đóng gói soda theo (gói 12 lon), 1 hộp gồm 2 x (gói 12 lon), và 1 palet có 40 hộp (gói 12 lon). Vì vậy, hoàn toàn có thể đóng cùng 1 lon soda theo các hệ thống phân cấp khác nhau. Điều quan trọng cần lưu ý là chỉ xét những mặt hàng đã được đăng ký với Tổ chức Đăng ký Toàn cầu. Trong ví dụ nêu trên, lon soda, gói 6 lon, gói 12 lon, các hộp soda, các palet soda nói trên tất cả đều phải được đăng ký riêng với Tổ chức Đăng ký Toàn cầu, mỗi trong chúng được phân định bởi GTIN duy nhất của chính chúng. Tuy nhiên, Tổ chức Đăng ký Toàn cầu có thể không biết có bao nhiêu cấp hợp vào để tạo nên từng hệ thống phân cấp. Chức năng này được thực hiện tại Dữ liệu Dùng chung Ban đầu.

2.3.1.1. Các quy tắc có hiệu lực

Các quy tắc có hiệu lực được sử dụng trong GDSN để bắt buộc các quy tắc kinh doanh liên đới giữa các Bên, các mặt hàng và giá cả của chúng. Ví dụ, có đến trên 20 các quy tắc có hiệu lực khác nhau được Tổ chức Đăng ký Toàn cầu sử dụng với các thông điệp XML RCI. Các quy tắc có hiệu lực cũng rất quan trọng trong GDSN vì hầu hết các quy tắc có hiệu lực này xuất hiện cả bên ngoài lược đồ. Mặc dù có thể nhúng các quy tắc có hiệu lực vào lược đồ một cách dễ dàng hơn, kinh nghiệm chỉ ra rằng do các quy tắc có hiệu lực có thể thay đổi, như cập nhật các giá trị trong danh sách mã, việc không phải phát hành một bộ các lược đồ mỗi lần có một quy tắc có hiệu lực thay đổi là rất quan trọng. Vì vậy, việc có được các quy tắc có hiệu lực mở rộng đối với lược đồ, hệ thống Đăng ký Toàn cầu và các Dữ liệu Dùng chung có thể chỉnh sửa mà không phải tiến hành làm mới toàn bộ các lược đồ mỗi khi có sự thay đổi.

2.3.2. Đăng ký Đăng ký mặt hàng theo catalog (CIS)

Việc Đăng ký mặt hàng theo catalog là thông điệp kinh doanh được sử dụng để truyền đi một yêu cầu (mà do người nhận dữ liệu tạo ra) đối với thông tin mặt hàng thương mại, với mục đích đồng bộ hóa dữ liệu này với Nguồn dữ liệu. Quá trình này được mô tả trong Hình vẽ 2-5.



Hình vẽ 2-5 Quá trình đăng ký Đăng ký mặt hàng theo catalog

3

So khớp đăng ký mặt hàng

theo catalog

Đăng ký

Toàn cầu

2

Đăng ký mặt hàng theo

catalog

Kho

DL Nguồn

Kho DL Người nhận

1 Đăng ký

mặt hàng

Người nhận

Dữ liệu

1. Đầu tiên, Người nhận dữ liệu tải các tiêu chuẩn dùng cho đăng ký thông tin mặt hàng

2. Với thông tin này, Dữ liệu Người nhận Dùng chung tạo ra một Đăng ký mặt hàng theo catalog sử dụng các tiêu chí sau:

Thông điệp

a. GTIN

b. GLN của Nhà Cung cấp thông tin

c. Thị trường mục tiêu của nơi mà dự định sẽ bán GTIN

d. Mã Phân loại sản phẩm toàn cầu (GPC)

- và -

e. Tình trạng và một số ngày tháng liên quan (ngày sản xuất, ngày lưu kho sau cùng)

f. Dữ liệu Dùng chung mà có tính pháp lý đối với Đối tác thương mại và các giấy tờ đặt mua hàng của họ.

3. Thông tin này được đăng ký với hệ thống Đăng ký Toàn cầu nếu nó được thông qua

4. Quá trình so khớp Đăng ký toàn cầu bắt đầu

Thông điệp Đăng ký mặt hàng theo catalog được xác định hoàn toàn theo các tiêu chuẩn và tất các các Dữ liệu Dùng chung phải sử dụng cùng những thông điệp và các quy tắc có hiệu lực này. Phương thức mà Người nhận dữ liệu tạo lập các đăng ký mua hàng hay Nguồn dữ liệu nhận được các đăng ký mua hàng tùy thuộc vào các lựa chọn của họ đối với các Dữ liệu Dùng chung và thỏa thuận chung giữa họ. Ví dụ, hoàn toàn có thể sử dụng giao diện người dùng đồ họa để tạo lập các đăng ký mua hàng và nhận thông tin.

2.3.3. Quá trình so khớp Đăng ký Toàn cầu

Sau đó, hệ thống Đăng ký Toàn cầu thực hiện quá trình so khớp. Mỗi khi một việc Đăng ký mặt hàng theo catalog xuất hiện hoặc một giấy Đăng ký mặt hàng theo catalog xuất hiện, hệ thống Đăng ký Toàn cầu thực hiện một tiến trình so khớp để so sánh các mặt hàng với các đăng ký mua hàng và ngược lại, sử dụng tiêu chí chung trong cả hai dạng đăng ký như minh họa trong Hình vẽ 2-6.



Hình vẽ 2-6 Mặt hàng đã Đăng ký toàn cầu I Quá trình so khớp đăng ký mặt hàng

Đăng ký mặt hàng theo catalog Giấy đăng ký mặt hàng theo

catalog

GTI N

GLN Nhà cung cấp thông tin

Thị trường mục tiêu

Mã GPC

Mặ t hà ng /

Quá trình so

khớp đăng ký

mặt hàng

GTI N

GL N Nhà cung cấp thông tin

Thị trường mục tiêu

Mã GPC

Kết quả của việc so khớp thành công là: hệ thống Đăng ký toàn cầu gửi Đăng ký mặt hàng theo catalog đã so khớp này tới mỗi Dữ liệu Dùng chung có mặt hàng đã được đăng ký mà khớp với các tiêu chí của đăng ký mặt hàng cụ thể đó.

2.3.4. Công bố mặt hàng và Phân phối mặt hàng

Khi mà hệ thống Đăng ký toàn cầu hoàn thành quá trình so khớp và gửi Đăng ký đã so khớp tới các Dữ liệu Dùng chung Ban đầu thích hợp, các Dữ liệu Dùng chung Ban đầu phải so khớp Công bố mặt hàng với các Đăng ký mặt hàng nhận được. Khi một Nguồn dữ liệu công bố thông tin mặt hàng của nó, Dữ liệu Dùng chung Ban đầu tạo lập một Thông báo mặt hàng theo catalog có chứa toàn bộ thông tin về mặt hàng này, bao gồm toàn bộ hệ thống phân cấp của sản phẩm. Ngoài ra, Dữ liệu Dùng chung Ban đầu cũng bổ sung mục mặt hàng này vào danh sách đồng bộ hóa của nó. Danh sách đồng bộ hóa này chứa đựng tất cả các mặt hàng đã công bố và kết quả của quá trình đồng bộ hóa với bất cứ những thay đổi nào trong tương lai, dù Người nhận dữ liệu có hay không quan tâm đến việc nhận được các cập nhật đối với thông tin đó theo cách tự động. Thông báo mặt hàng theo catalog này được gửi đi ngay tức khắc từ Dữ liệu Dùng chung Ban đầu tới Dữ liệu Người nhận Dùng chung. Nó không đi qua hệ thống Đăng ký Toàn cầu dù hệ thống này thuận tiện cho việc kết nối nhưng lại không liên quan gì đến việc trao đổi các thông điệp thực sự, được minh họa trong Hình vẽ 2-7.



Hình vẽ 2-7 Tiến trình phân phối dữ liệu mặt hàng

Đăng ký

Toàn cầu

Kho DL

Nguồn

2

Thông báo mặt hàng theo catalog

Kho DL

Người nhận

Nguồn

Công bố Mặt hàng

1

Thông báo

mặt hàng

3

Người

Dữ liệu Nhận DL

Như đã đề cập ở trên, thông điệp trong mạng lưới hệ thống, Thông báo mặt hàng theo catalog được xác định hoàn toàn theo các chuẩn và mọi Dữ liệu Dùng chung phải sử dụng cùng các thông điệp và các quy tắc có hiệu lực. Phương thức theo đó các Nhà Công bố nguồn dữ liệu hoặc Người nhận dữ liệu nhận được sẽ tùy thuộc vào các lựa chọn của họ đối với các Dữ liệu Dùng chung và thỏa thuận chung giữa họ. Ví dụ, có thể sử dụng giao diện người dùng đồ họa để công bố thông tin hay nhận thông tin. Việc đó cũng có thể được thực hiện sử dụng các bộ thông điệp EDI hiện có mà chúng không có liên quan gì với GDSN.

Khi mà Người nhận dữ liệu nhận được thông tin mặt hàng, họ sẽ phải quyết định có hay không việc tiếp tục đồng bộ hóa dữ liệu với Nguồn dữ liệu. Quyết định này dựa trên một số yếu tố liên quan đến mối quan hệ kinh doanh giữa Người nhận dữ liệu và Nguồn dữ liệu. Khi quyết định này được đưa ra, nó sẽ phải được thông tin qua GDSN ngược trở lại cho Nguồn dữ liệu.

2.3.5. Xác nhận mặt hàng theo catalog

Khi Người nhận dữ liệu ra quyết định, thông tin ngược trở lại với Nguồn dữ liệu được tạo ra và Dữ liệu Người nhận Dùng chung tạo lập một thông điệp, được gọi là Xác nhận mặt hàng theo catalog, như được minh họa trong Hình vẽ 2-8.



Hình vẽ 2-8 Tiến trình Xác nhận mặt hàng theo catalog

Đăng ký

Toàn cầu

Kho DL

Nguồn Xác nhận mặt hàng

Theo catalog

Kho DL Người nhận

Nguồn

Dữ liệu

3


2

1


Người nhận

Dữ liệu

Thông điệp này có chứa quyết định về việc Người nhận dữ liệu có hay không việc tiếp tục đồng bộ hóa thông tin về mặt hàng. Các trạng thái có thể thông tin trên thông điệp này là:

■ Đồng bộ hóa: Dữ liệu được tích hợp, đồng bộ hóa và bổ sung vào danh sách đồng bộ hóa

■ Chấp nhận: Người nhận đã nhận được dữ liệu nhưng không ra quyết định đối với dữ liệu này

■ Loại bỏ: Dữ liệu sẽ không còn được đồng bộ hóa cũng không được cập nhật

■ Xem xét: Nguồn dữ liệu xem xét lại dữ liệu do nhận được dữ liệu không nhất quán nên cản trở tiến

trình đồng bộ hóa

Nếu không nhận được xác nhận nào, dữ liệu tiếp tục được cập nhật cho đến khi Người nhận dữ liệu trả lời bằng trạng thái “Loại bỏ”.

Ngoài ra, các trạng thái Xác nhận mặt hàng theo catalog còn có thêm trạng thái sau: nếu dữ liệu được đặt vào trạng thái “Xem xét” hoặc “Loại bỏ”, Người nhận dữ liệu có thể phản hồi lại bằng một tập các câu trả lời chi tiết để chỉ ra chính xác có lỗi nào trong dữ liệu, tiến trình nào nên sử dụng để sửa chữa lỗi đó và gửi lại thông tin chính xác. Danh sách mã các trạng thái Xác nhận mặt hàng theo catalog sẽ cung cấp một giá trị mã và một mô tả cho biết lỗi đó là gì. Danh sách mã hoạt động chính xác cung cấp danh sách các mã hoạt động chính xác trong một phản hồi Xác nhận mặt hàng theo catalog.

Khi Dữ liệu Dùng chung Ban đầu nhận được Xác nhận mặt hàng theo catalog này, nó có thể cập nhật danh sách đồng bộ hóa và có thể truyền thông tin này đến Dữ liệu Dùng chung Ban đầu. Việc này đóng vòng lặp và kết thúc tiến trình đồng bộ hóa dữ liệu đối với dữ liệu đưa vào đồng bộ hóa ban đầu. Với thông tin có trong danh sách đồng bộ hóa, Dữ liệu Dùng chung Ban đầu xác định những Dữ liệu Dùng chung nào (và những Người nhận dữ liệu nào) sẽ gửi những cập nhật của dữ liệu mặt hàng đã được đồng bộ hóa. Bằng cách này, dữ liệu mặt hàng luôn luôn duy trì được cập nhật mới.



2.3.6. Yêu cầu về Thông báo mặt hàng theo catalog (RFCIN)

Một yêu cầu về Thông báo mặt hàng theo catalog (RFCIN) có chức năng giống như một Đăng ký mặt hàng theo catalog. Tuy nhiên, đây là một yêu cầu chỉ một lần đối với dữ liệu sẽ được gửi (gửi lại). Yêu cầu về thông báo không được lưu trữ trong hệ thống Đăng ký toàn cầu sau khi tiến trình so khớp xảy ra. RFCIN chỉ thực thi một lần và sau đó bị Dữ liệu Dùng chung Ban đầu loại đi.

Với các mặt hàng theo catalog đã được đồng bộ hóa trước đó (ví dụ, trong danh sách đồng bộ hóa) hoặc loại bỏ, yêu cầu về thông báo sẽ thiết lập lại các trạng thái xác nhận mà nó loại bỏ mặt hàng theo catalog ra khỏi danh sách đồng bộ hóa. Cách sử dụng chính đối với một RFCIN là khôi phục hệ thống bên trong sau khi sảy ra một lỗi nghiêm trọng, nơi mà thông tin về mặt hàng này phải tự xây dựng lại bên trong hệ thống đó.

3. Tham gia GDSN

Các đối tác thương mại có mong muốn tham gia vào hiệp hội GDSN cần liên hệ với Tổ chức thành viên GS1 (MO) tại quốc gia mà công ty của họ có trụ sở. Các Dữ liệu Dùng chung phải được chứng thực là một bộ phận của GDSN. Tất cả các bên quan tâm nên xem trên trang web của tổ chức GDSN GS1 để biết được các hướng dẫn gia nhập thành viên tại địa chỉ http://www.gs1.orgIproductssolutionsIgdsnI.

Mặt khác, một danh sách các Dữ liệu Dùng chung đã chứng thực có tại địa chỉ:

http:IIwww.gs1.orgIdocsIgdsnIgdsn_certified_data_pools.pdf

3.1. Dữ liệu Dùng chung sẵn sàng đưa vào kết nối

Khi quyết định tham gia Hiệp hội GDSN, một Dữ liệu Dùng chung mới phải được kết nối với Hiệp hội GDSN để khởi động tiến trình Đăng ký. Một Dữ liệu Dùng chung mới sẽ cần thiết lập một kết nối chính với mọi sự giao thiệp trong GDSN. Dữ liệu Dùng chung này cũng cần phải chuẩn bị thông tin như địa chỉ URL của Dữ liệu Dùng chung cho tất cả các khu vực (các môi trường), địa chỉ IP, thông tin chứng thực kỹ thuật số và thông tin liên lạc. Một nhãn ghi sẽ được nhập vào hệ thống theo dõi của GDSN đối với Dữ liệu Dùng chung này cùng với mọi thông tin có liên quan.

Các Dữ liệu Dùng chung này và hệ thống Đăng ký toàn cầu là chủ thể tôn trọng triệt để các điều khoản của Thỏa thuận mức dịch vụ GDSN [SLA] cũng như Chính sách sử dụng chấp nhận GDSN [AUL]. Cả hai tài liệu này đã được phổ biển bởi Hiệp hội GDSN.

3.2. Chứng nhận GDSN

Tất cả các Dữ liệu Dùng chung tham gia GDSN phải được chứng thực. Tiêu chí chứng thực và các kế hoạch kiểm tra dựa trên tiêu chuẩn đã được phê chuẩn và chức năng đã công bố của GDSN GS1. Đại lý cấp giấy chứng nhận triển khai các bài kiểm tra xác nhận dựa trên các tiêu chí được phát triển và phê chuẩn bởi Hiệp hội GDSN trong Giai đoạn Phát triển Quan trọng của Phiên bản GDSN (the GDSN Release Materials Development Phase).

Sau khi việc cấp giấy chứng nhận hoàn tất, Dữ liệu Dùng chung sẽ được nhập vào hệ thống GR của nhóm Hỗ trợ Kỹ thuật GDSN sau khi được Hiệp hội GDSN phê duyệt.

Sau đó, Dữ liệu Dùng chung sẽ có thể bắt đầu quá trình thử nghiệm trong môi trường kiểm tra / beta.

3.3. Quản trị thay đổi

Phạm vi và tính hợp thời của bất kỳ phiên bản GDSN mới nào được dựa trên lược đồ phương pháp GDSN. Lược đồ phương pháp GDSN này đưa ra một tổng quan ở mức cao về các ưu tiên phát triển của Nhóm Người sử dụng GDSN.

Dựa trên những ưu tiên được nêu trong lược đồ phương pháp GDSN và các nguồn tài nguyên sẵn có, Nhóm Người sử dụng GDSN có thể xác định số lượng và loại (chính hay phụ) của phiên bản dự kiến trong năm. Phạm vi và kế hoạch phát hành cũng bao gồm Phiên bản của Phân loại Sản phẩm Toàn cầu được thông qua đối với phiên bản GDSN cụ thể cũng như các phiên bản đã thông qua các danh sách mã

http://www.gs1.orgiproductssolutionsigdsni/

http://www.gsl.orgidocsigdsnigdsn_certified_data_pools.pdf/



được quản trị từ bên ngoài.

Chú ý: Các phiên bản GDSN, GSMP và GPC có thể đang không được đồng bộ hóa và khác nhau

theo thời gian. Ngoài ra, một số tệp lược đồ XML cũng có thể ở những phiên bản khác so với phiên bản GDSN chung.

4. Sử dụng XML trong GS1 và GDSN

4.1. Các tiêu chuẩn XML GS1

Các tiêu chuẩn XML GS1 là các tiêu chuẩn dùng cho thương mại hợp tác được người sử dụng thống nhất trên toàn cầu xác định ra. Người sử dụng toàn cầu gồm các công ty thành viên GS1 nằm dưới sự chỉ đạo của GS1 và các tổ chức thành viên của nó. Các đặc trưng cơ bản của các tiêu chuẩn là định hướng khách hàng dựa trên sự đồng thuận chung, được xây dựng phối hợp bởi GS1 và các công ty thành viên của các tổ chức thành viên GS1 trong một quy trình mở khuyến khích sự tham gia trên toàn cầu.

Các tiêu chuẩn cung cấp một cách tiếp cận rộng mở và linh hoạt đối với giao dịch thương mại điện tử business-to-business. Chúng có tính ứng dụng đa ngành và toàn cầu. Các tiêu chuẩn XML GS1dựa trên các đặc tính kỹ thuật XML World Wide Web Consortium (W3C). W3C là một tổ chức tiêu chuẩn chuyên phát triển công nghệ tương thích (đặc điểm kỹ thuật, hướng dẫn sử dụng, phần mềm và các công cụ) cho thương mại dựa trên nền tảng internet và truyền thông. Các đặc trưng nền tảng của cấu trúc GS1 là một chu kỳ phát triển các tiêu chuẩn rút gọn; phát triển các tiêu chuẩn nhất quán, có khả năng tái sử dụng và có khả năng tương tác tin nhắn. Cấu trúc XML GS1 là mô-đun. Cấu trúc GS1 sử dụng đặc trưng này để tổ chức các lược đồ thành các lớp logic trong đó mỗi lớp thực hiện một chức năng cụ thể.

Chi tiết về Hướng dẫn sử dụng kỹ thuật XML GS1 có trên trang web GS1 tại địa chỉ:

http:IIwww.gs1.orgIecomIxmlIimplementationIguide

4.2. Hosting của các tiêu chuẩn (Máy chủ chứa nội dung các tiêu chuẩn)

Các tiêu chuẩn thông điệp kinh doanh (BMS) có trong các phiên bản trước kia, hiện tại và mới nhất hiện có trên trang webside của GS1 tại địa chỉ:

http:IIwww.gs1.orgIgsmpIkcIecomIxmlIgdsn_grid

Các lược đồ XML GS1 và các tập tin (file) ví dụ cụ thể cho GDSN có trong các Gói tin thực thi và sẵn sàng cho người dùng tải về.

4.3. Các lược đồ XML GDSN

Các lược đồ GDSN dựa trên các quy ước của tiêu chuẩn XML GS1. Các tiêu chuẩn này phát hành trên cơ sở một phiên bản. Từ khi công bố tài liệu này, các Tiêu chuẩn XML GS1 phiên bản 2.7.3 hỗ trợ cho GDSN. Hệ thống Đăng ký Toàn cầu GS1 đăng tải các lược đồ này trong hai môi trường: thử nghiệm và sản phẩm đóng gói. Các danh mục thư mục của các lược đồ này có các địa chỉ URL như sau:

■ Trang thử nghiệm: http:IIwww.gdsregistry.orgI2.7I

■ Trang sản phẩm đóng gói: http:IIwww.gs1globalregistry.netI2.7I

4.4. Các tài liệu XML GDSN

Người gửi các thông điệp XML GDSN có trách nhiệm đảm bảo rằng các thông điệp XML GDSN được gửi đi là lược đồ hợp lệ (phù hợp với Lược đồ XML GDSN tương ứng). Thông tin chi tiết về các lược đồ XML và tính hiệu lực của các tài liệu XML cụ thể có trong tài liệu Hướng dẫn Sử dụng Kỹ thuật XML.

Để các tài liệu Lược đồ XML GDSN có hiệu lực, tất cả các tài liệu XML GDSN cụ thể cũng cần phải tuân theo các quy tắc sau đây:

■ Các tài liệu XML GDSN cụ thể KHÔNG NÊN khai báo không gian tên tại các yếu tố bất kỳ trong tài liệu đó. Tất cả các khai báo không gian tên NÊN đặt tại phần tử gốc (Tài liệu kinh doanh tiêu

http://www.gsl.orgiecomixmliimplementationiguide/

http://www.gsl.orgigsmpikciecomixmligdsn_grid/

http://www.gdsregistry.orgi2.7i/

http://www.gslglobalregistry.neti2.7i/



chuẩn).

■ Các tài liệu XML GDSN cụ thể NÊN bao gồm các khai báo không gian tên tại phần tử gốc (Tài liệu kinh doanh tiêu chuẩn) cho tên của không gian tên sau đây:

□ http:IIwww.w3.orgI2001IXMLSchema-instance

□ http:IIwww.unece.orgIcefactInamespacesIStandardBusinessDocumentHeader

□ urn:ean.ucc:2

□ urn:ean.ucc:gdsn:2

■ KHUYẾN CÁO: các t i ền tố không gian tên của lược đồ XML GS1 được sử dụng cho các tên của không gian tên nói t rên t rong:

□ xmlns:sh=”http:IIwww.unece.orgIcefactInamespacesIStandardBusinessDocumentHeader”

□ xmlns:eanucc=”urn:ean.ucc:2”

□ xmlns:gdsn=”urn:ean.ucc:gdsn:2”

■ Một Bên nhận thông điệp GDSN PHẢI KHÔNG gặp lỗi với thông điệp GDSN chỉ do sự tồn tại của tiền tố không gian tên bất kỳ.

■ Các tài liệu XML GDSN cụ thể PHẢI KHÔNG chứa đựng các khai báo không gian tên cho các phần mở rộng mà không hiện hữu trong thông điệp.

■ T ấ t c ả m ọ i tài liệu XML GDSN cụ thể PHẢI chứa các địa chỉ URL đúng quy cách đầy đủ để chỉ ra các địa chỉ ra lược đồ sản phẩm như giá trị cho thuộc tính ĐịachỉLượcđồ (schemaLocation).

Dưới đây là một đoạn mã của thông điệp KhaibáoMặthàngTheoCatalog (CatalogItemNotification) minh họa cho việc sử dụng thuộc tính ĐịachỉLượcđồ (schemaLocation).

<sh:StandardBusinessDocument xsi:schemaLocation="http:IIwww.unece.orgIcefactInamespacesIStandardBusinessDocumentHeader http:IIwww.gs1globalregistry.netI2.7IschemasIsbdhIStandardBusinessDocumentHeader.xsd urn:ean.ucc:2 http:IIwww.gs1globalregistry.netI2.1IschemasICatalogueItemNotificationProxy.xsd">

5. Truyền tải thông điệp

5.1. Giao thức truyền thông

Giao thức EDI với 2 câu lệnh có khả năng ứng dụng trên internet (EDIINT AS2) là giao thức truyền thông duy nhất đã được phê chuẩn sử dụng cho GDSN. Bạn đọc có thể tham khảo tài liệu sau đây để tìm hiểu về cách sử dụng giao thức này “Hướng dẫn sử dụng truyền tải thông tin EDIINT AS1 và AS2 ”. Tài liệu này đang sẵn sàng trên trang website của GS1 tại địa chỉ:

http:IIwww.gs1.orgIdocsIgsmpIEDIINT_AS1_AS2_Transport_Comm_Guide_i1.pdf

6. Các đặc trưng GDSN

6.1. Các quy tắc có hiệu lực

Các quy tắc có hiệu lực của tiêu chuẩn DGSN được liệt kê trong tài liệu đăng tải trên trang web của GS1 tại địa chỉ: http:IIwww.gs1.orgIsitesIdefaultIfilesIdocsIgsmpIxmlI2_7_0IBMS_GDSN_Validation_Rules_r2p7p0_i1. 3.0_17_Feb_2010.xls

Tất cả ID của các thông điệp báo lỗi tiêu chuẩn và các thông điệp báo lỗi PHẢI được sử dụng như đã định rõ trong tài liệu này.

6.2. Các phê chuẩn riêng với Thị trường mục tiêu (TMSV)

Từ khi có những trường hợp mà các phê chuẩn riêng đối với thị trường mục tiêu cần phải được thi hành,

http://www.w3.orgi200lixmlschema-instance/

http://www.unece.orgicefactinamespacesistandardbusinessdocumentheader/




http://www.gslglobalregistry.neti2.7ischemasisbdhistandardbusinessdocumentheader.xsd/

http://www.gslglobalregistry.neti2.lischemasicatalogueitemnotificationproxy.xsd/

http://www.gsl.orgidocsigsmpiediint_asl_as2_transport_comm_guide_il.pdf/



điều quan trọng là phải xác định xem các quy tắc có hiệu lực đó song hành tồn tại với các Quy tắc có hiệu lực của GDSN có phạm vi toàn cầu đã được đưa vào sử dụng trước đó (Mục 6.1). Dưới đây là các quy tắc phải tuân theo trong trường hợp này:

■ Một TMSV PHẢI KHÔNG được sử dụng để làm yếu đi các đặc trưng của một thuộc tính cốt lõi (ví dụ từ có tính bắt buộc sang có tính không bắt buộc);

■ Một TMSV PHẢI KHÔNG được sử dụng để làm yếu đi hiệu lực hiện thời có tính toàn cầu;

■ Một TMSV PHẢI được hỗ trợ bởi Tổ chức thành viên GS1 có nghĩa vụ về pháp lý trong các vấn đề liên quan đối với thị trường mục tiêu;

■ Thị trường mục tiêu của Đăng ký mặt hàng theo catalog (RCI) xác định những phê chuẩn riêng với thị trường mục tiêu nào sẽ được thực hiện dựa vào RCI đó;

■ Những phê chuẩn riêng với thị trường mục tiêu PHẢI được đặt tại cấp Mã Quốc gia của Thị trường mục tiêu tương ứng (PHẢI KHÔNG đặt tại cấp chia nhỏ hơn của Thị trường mục tiêu).

■ Thông báo mặt hàng theo catalog (CIN) được gửi bởi Dữ liệu Dùng chung Ban đầu PHẢI tuân theo tất cả các phê chuẩn riêng với thị trường mục tiêu.

6.3. Header của tài liệu kinh doanh tiêu chuẩn UN/CEFACT sử dụng trong GDSN

Header của tài liệu kinh doanh tiêu chuẩn (SBDH) của Trung tâm Hỗ trợ thương mại và Kinh doanh điện tử của Liên Hiệp Quốc (UNICEFACT) cung cấp thông tin về các tuyến gửi và xử lý các tài liệu XML cụ thể. SBDH được thiết kế sao cho không phụ thuộc vào giao thức truyền tải cụ thể được sử dụng. Thông tin chứa đựng trong SBHD có thể được các ứng dụng truyền thông sử dụng để xác định tuyến gửi mà không có liên quan gì đến giao thức truyền tải.

SBDH cũng có thể tùy chọn cung cấp thông tin về phạm vi kinh doanh và dịch vụ kinh doanh. Trong các lược đồ XML GS1 phiên bản thứ 2 và sau đó, SBHD được thiết kế để trở thành một phần không thể thiếu của các tài liệu XML cụ thể (trong các tiêu chuẩn khác, SBDH có thể là một đối tượng liên kết với các tài liệu XML cụ thể).

Để biết thêm chi tiết về Đặc điểm kỹ thuật UNICEFACT về SBDH, các nguyên tắc sử dụng chúng và các lược đồ XML tương ứng, mời xem thêm tại địa chỉ sau:

http:IIwww.gs1.orgIgsmpIkcIecomIxmlIxml_sbdh

6.3.1. Sử dụng SBDH như thế nào trong GDSN

Các lược đồ SBDH được sử dụng trong GDSN được đăng tải và giải thích rõ trong Mục 4.3 - Các lược đồ XML GDSN và Mục 4.4 - Các tài liệu cụ thể XML GDSN.

Khi mà cách sử dụng SBDH trong GDSN được tuân theo các đặc điểm kỹ thuật SBDH được đề cập ở trên, các tiêu chuẩn GDSN áp đặt ngữ nghĩa bổ sung lên cách sử dụng nó trong mạng lưới GDSN. Các mục tiếp theo đây liệt kê các điều bắt buộc này.

6.3.1.1. Các quy tắc sử dụng SBDH

Dưới đây là các quy tắc sử dụng cơ bản của SBDH trong GDSN:

■ Header của tài liệu kinh doanh tiêu chuẩn là TÙY CHỌN phía dưới chuẩn UNICEFACT SBDH, tuy nhiên khi công bố để sử dụng trong GDSN nó là BẮT BUỘC. Phần GS1 của thông điệp được bao trùm bởi header (và KHÔNG gửi đi trong một phần MIME riêng biệt), và yếu tố Header của tài liệu kinh doanh tiêu chuẩn PHẢI được sử dụng.

■ Phiên bản của Header (HeaderVersion) PHẢI được thiết lập thành ‘1.0’.

■ Các phần tử gửi (Sender) và nhận (Receiver) PHẢI được sử dụng chỉ 1 lần.

□ Giá trị của phần tử định danh (Identifier) trong các phần tử Gửi (Sender) và Nhận (Receiver) PHẢI là một GLN của thực thể truyền thông tương ứng mà tham gia trực tiếp trong trao đổi thông điệp. Phần tử Nhận trong thông điệp phản hồi so khớp với phần tử Gửi trong thông điệp yêu cầu.

□ Thuộc tính Quyền (Authority) của phần tử định danh (Identifier) dưới các phần tử Sender và

http://www.gsl.orgigsmpikciecomixmlixml_sbdh/



Receiver PHẢI thiết lập thành ‘EAN.UCC’.

□ Phần tử Thông tin liên lệ (ContactInformation element) PHẢI KHÔNG được sử dụng.

■ Phần tử Chỉ số tài liệu (DocumentIdentification) PHẢI được sử dụng

□ Phần tử Chuẩn (Standard) PHẢI thiết lập thành ‘EAN.UCC’.

□ Phần tử Phiên bản kiểu loại (TypeVersion) luôn được thiết lập giống như của phiên bản lược đồ hiện thời. Phiên bản lược đồ hiện thời (như của xuất bản phẩm của tài liệu này) là ‘2.7’ và nên được thiết lập giống như vậy.

□ Phần tử Định danh cụ thể (InstanceIdentifier) PHẢI luôn được thiết lập với giá trị là duy nhất trong phạm vi của người gửi. Điều này áp dụng cho cả hai loại thông điệp gốc cũng như với thông điệp phản hồi. Hãy chú ý tới điều này trong yêu cầu dạng mẫu và thông điệp phản hồi dạng mẫu được trích đoạn sau đây.

Chú ý: Như đã giải thích trong Sách hướng dẫn sử dụng kỹ thuật XML, Phiên bản Chuẩn XML GS1 về việc bổ sung hướng dẫn sử dụng SBDH cũng xác định một Lớp Thông điệp chỉ với mục đích: hỗ trợ dưới dạng côngtennơ cho một hay nhiều hơn các giao dịch. Phần tử thông điệp đại diện cho Lớp Thông điệp có thể bị phản kháng trong tương lai, nhưng với hiện tại nó cần phải được thiết lập sao cho bao gồm cả phần tử Chỉ số thực thể (entityIdentification). Đối với giá trị của phần tử Chỉ số tạo lập duy nhất (uniqueCreatorIdentification) (một phần tử con của phần tử entityIdentification của phần tử thông điệp), ngữ nghĩa của nó CÓ THỂ giống với giá trị của InstanceIdentifier. Đối với giá trị của phần tử Người sở hữu nội dung (contentOwner) (một phần tử con của phần tử entityIdentification của phần tử thông điệp), người đọc có thể xem thêm ở mục 6.7 - Người sở hữu nội dung.

□ Phần tử Kiểu loại (Type) cho biết kiểu loại của tài liệu GDSN chuẩn bị gửi đi. Phần tử này là BẮT BUỘC dưới chuẩn SBDH UNICEFACT. Trong GDSN, nó phải được sử dụng. Với bất kỳ thông điệp phản hồi GDSN nào, phần tử này PHẢI thiết lập thành GDSNResponse. Với những thông điệp GDSN mà không phải là thông điệp phản hồi, thông tin như vậy PHẢI so khớp với tên của phần tử con của phần tử truyền tải documentCommandOperand. Trong ví dụ dưới đây, phần tử này khai báo catalogueItemNotification.

□ Phần tử Đa kiểu (MultipleType) PHẢI KHÔNG được sử dụng.

□ CreationDateAndTime là BẮT BUỘC dưới chuẩn SBDH UNICEFACT. Trong GDSN, nó PHẢI được sử dụng để thông tin về ngày tháng và thời gian khi ‘ứng dụng khởi đầu tài liệu’ tạo lập nên tài liệu. Vai trò này sẽ hoạt động một cách đặc thù theo đối tác kinh doanh và sẽ khác biệt đặc thù với thời gian đánh dấu của thông điệp đó nhờ phần mềm EDIINT AS2.

□ Manifest element PHẢI KHÔNG được sử dụng.

■ BusinessScope là TÙY CHỌN dưới chuẩn UNICEFACT SBDH. Trong GDSN, BusinessScope:

□ PHẢI KHÔNG được sử dụng trong thông điệp yêu cầu.

□ PHẢI được sử dụng trong các thông điệp phản hồi.

□ Phần tử Phạm vi (Scope) PHẢI được sử dụng chỉ 1 lần duy nhất.

- Phần tử kiểu loại (Type) PHẢI thiết lập thành ‘GDSN’.

- Phần tử Định danh cụ thể (InstanceIdentifier) - là phần tử con của phần tử Phạm vi (Scope) - không được sử dụng trong chuẩn tiêu chuẩn GDSN hiện thời, nhưng khi nó được khai báo như là một phần tử lược đồ XML bắt buộc, nó cần phải thiết lập. Giá trị của nó CÓ THỂ so khớp với giá trị của phần tử Định danh cụ thể (InstanceIdentifier) – là phần tử con của phần tử Chỉ số tài liệu (DocumentIdentification).

- Phần tử Định danh (Identifier) PHẢI KHÔNG được sử dụng.

- Phần tử thông tin tương quan (CorrelationInformation) PHẢI được sử dụng chỉ 1 lần duy nhất.

- Phần tử Thời gian và ngày tháng tạo lập tài liệu yêu cầu (RequestingDocumentCreationDateTime) CÓ THỂ được sử dụng. Nếu sử dụng, giá trị của nó PHẢI so khớp với giá trị của phần tử Thời gian và ngày tháng tạo lập (CreationDateAndTime) của thông điệp yêu cầu.

- Giá trị của phần tử Định danh cụ thể tài liệu yêu cầu (RequestingDocumentInstanceIdentifier) PHẢI



so khớp với giá trị của phần tử Định danh cụ thể (InstanceIdentifier) – là con của phần tử Chỉ số tài liệu (DocumentIdentification) trong thông điệp yêu cầu.

- Phần tử Ngày tháng phản hồi mong muốn (ExpectedResponseDateTime) CÓ THỂ được sử dụng.

- Phần tử Dịch vụ kinh doanh (BusinessService) PHẢI KHÔNG được sử dụng.



6.3.1.2. Diễn giải các quy tắc sử dụng SBDH

Dưới đây là một đoạn trích thông điệp yêu cầu được diễn giải, minh họa các quy tắc sử dụng SBDH trong GDSN.

<sh:StandardBusinessDocument> I* MANDATORY *I

<sh:StandardBusinessDocumentHeader> I* MANDATORY *I

<sh:HeaderVersion>1.0<Ish:HeaderVersion> I* MANDATORY *I

I* PRIMARY MANDATORY MUST NOT USE CONTACT INFORMATION *I

. <sh:Identifier Authority="EAN.UCC">6903148000007<Ish:Identifier>

<Ish:Sender>

I* PRIMARY MANDATORY MUST NOT USE CONTACT INFORMATION *I

<sh:Identifier Authority="EAN.UCC">2203148000007<Ish:Identifier>

<Ish:Receiver>

<sh:DocumentIdentification> I* MUST NOT USE MULTIPLE TYPE *I

<sh:Standard>EAN.UCC<Ish:Standard>

<sh:TypeVersion>2.7<Ish:TypeVersion>

<sh:InstanceIdentifier>100002<Ish:InstanceIdentifier>

<sh:Type>catalogueItemNotification<Ish:Type>

<sh:CreationDateAndTime>2004-01-10T10:15:01Z<Ish:CreationDateAndTime>

<Ish:DocumentIdentification> I* MUST NOT USE MANIFEST *I

I* MUST NOT USE BUSINESS SCOPE *I

<Ish:StandardBusinessDocumentHeader>

<eanucc:message> /*START OF THE EAN.UCC PAYLOAD*/

<entityIdentification>

I* MAY BE THE SAME AS SBDH INSTANCE IDENTIFIER *I

<contentOwner>

<gln>6903148000007<Igln> I* SAME AS IN SBDH SENDER *I

<IcontentOwner>

<IentityIdentification>

<eanucc:transaction>

<command>

<eanucc:documentCommand>

<documentCommandHeader type="ADD">

<IdocumentCommandHeader>

<documentCommandOperand>

<gdsn:catalogueItemNotification"> I* MATCHES SBDH TYPE *I

<IdocumentCommandOperand>

<Ieanucc:documentCommand>

<Icommand>

<Ieanucc:transaction>

<Ieanucc:message>

<Ish:StandardBusinessDocument>



Đoạn dưới đây là một đoạn trích của thông điệp phản hồi, minh họa cho các quy tắc sử dụng của

SBDH trong GDSN. Hãy chú ý đến sự tương ứng của những giá trị khác nhau với những giá trị đã có

trong đoạn thông điệp (yêu cầu) phía trên.

<sh:StandardBusinessDocument>

<sh:StandardBusinessDocumentHeader>

<sh:HeaderVersion>1.0<Ish:HeaderVersion>

<sh:Sender> I* SAME AS SBDH RECEIVER IN THE REQUEST *I


<Ish:Sender>

<sh:Receiver> I* SAME AS SBDH SENDER IN THE REQUEST *I


<Ish:Receiver>

<sh:DocumentIdentification>

<sh:Standard>EAN.UCC<Ish:Standard>

<sh:TypeVersion>2.7<Ish:TypeVersion>


<sh:Type>GDSNResponse<Ish:Type>

<sh:CreationDateAndTime>2004-01-14T11:14:01Z<Ish:CreationDateAndTime>

<Ish:DocumentIdentification>

THE FOLLOWING ELEMENT (BUSINESS SCOPE) AND ITS SUBELEMENTS MUST BE USED FOR ALL RESPONDING MESSAGES AND ONLY FOR RESPONDING MESSAGES

<sh:BusinessScope>

<sh:Scope>

<sh:Type>GDSN<Ish:Type>


I* MAY BE THE SAME AS SBDH INSTANCE IDENTIFIER *I

I*MUST NOT USE IDENTIFIER *I

<sh:CorrelationInformation>

<sh:RequestingDocumentCreationDateTime>2004-01-10T10:15:01Z

I*SAME AS THE CREATION DATE AND TIME IN THE REQUEST*I

<Ish: RequestingDocumentCreationDateTime>

<sh:RequestingDocumentInstanceIdentifier>100002

I*SAME AS THE INSTANCE IDENTIFIER IN THE SBDH REQUEST*I

<Ish:RequestingDocumentInstanceIdentifier>

<Ish:CorrelationInformation> I*MUST NOT USE BUSINESS SERVICE*I

<Ish:Scope>

<Ish:BusinessScope>

<Ish:StandardBusinessDocumentHeader>

<eanucc:message>

…

<Ieanucc:message>

<Ish:StandardBusinessDocument>



6.4. Phản hồi trong GDSN

Có 4 kiểu thông điệp phản hồi trong There GDSN:

■ Phản hồi EANUCC (EANUCCResponse)

■ Phản hồi Đăng ký mặt hàng theo catalog (CatalogueItemRegistrationResponse)

■ Phản hồi Đăng ký thành viên (PartyRegistrationResponse)

■ Ngoại lệ GDSN (GDSNException)

EANUCCResponse biểu thị một phiên giao dịch đã thành công. Nó không phải là một phiên giao dịch hay một câu lệnh hoặc một tài liệu, mà chỉ là một chỉ báo công nhận một phiên giao dịch đã được xử lý.

CatalogItemRegistrationResponse và PartyRegistrationResponse cũng đáp ứng với cùng mục đích là chấp nhận thông điệp yêu cầu, nhưng chúng dành riêng được gửi bởi Tổ chức Đăng ký Toàn cầu dựa trên việc đăng ký một Đăng ký Mặt hàng theo catalog (RCI) hay một Đăng ký thành viên (RP) đã thành công.

Chú ý: Những điều này có khác nhau đôi chút ở chỗ các phản hồi tham chiếu tới chỉ số của Tài liệu Yêu cầu như thế nào (khi có trái ngược với Giao dịch Yêu cầu hoặc là Thông điệp).

GDSNException được sử dụng để biểu thị ngược trở lại tới người gửi những lỗi khác nhau có trong thông điệp (yêu cầu) ban đầu mà chúng có thể xảy ra trong quá trình xử lý thông điệp đó ở phía người nhận.

Ngoài ra, đề cập cụ thể tới kiểu phản hồi đơn, trong phần còn lại của đoạn văn bản này, chúng tôi sẽ sử dụng cách phân loại sau đây để nói đến một tập con các thông điệp phản hồi hợp thức:

■ Phản hồi GDSN (GDSN Response) – bao gồm cả 4 loại phản hồi

■ Phản hồi GDSN xác thực (Positive GDSN Response) – bao gồm Phản hồi Đăng ký Mặt hàng theo catalog (CatalogItemRegistrationResponse), Phản hồi Đăng ký Thành viên (PartyRegistrationResponse), và Phản hồi EANUCC (EANUCCResponse)

Sau đây là các quy tắc mà các thông điệp phản hồi GDSN bắt buộc phải tuân theo:

1. Phản hồi GDSN PHẢI tương ứng với một và chỉ một thông điệp yêu cầu, có nghĩa là nó không thể phản hồi cho nhiều hơn một thông điệp yêu cầu tại cùng một thời điểm.

2. Người nhận thông điệp yêu cầu GDSN mà thông điệp này bao gồm nhiều giao dịch CÓ THỂ đóng gói và gửi các thông điệp GDSN liên quan tới các yêu cầu giao dịch ban đầu hoặc như là một thông điệp phản hồi GDSN độc lập hoặc gồm nhiều các thông điệp phản hồi GDSN.

3. Nhiều thông điệp EANUCC và các phần tử Ngoại lệ CÓ THỂ được chứa trong một thông điệp phản hồi GDSN độc lập.

4. Phản hồi xác thực GDSN (Positive GDSN Response) có thuộc tính responseStatus PHẢI thiết lập thành ‘ACCEPTED’.

5. Chỉ số của Phản hồi xác thực GDSN PHẢI tương ứng với chỉ số phiên giao dịch của thông điệp yêu cầu.

. Phần tử Chỉ số tạo lập duy nhất (uniqueCreatorIdentification) và phần tử Chủ sở hữu nội dung (contentOwner) là con của phần tử Tài liệu nhận được / Chỉ số phản hồi trong một Phản hồi xác thực GDSN PHẢI được sao chép từ phần tử Chỉ số tạo lập duy nhất và từ phần tử Chủ sở hữu nội dung, mà chúng là con của phần tử Chỉ số thực thể. Chỉ số thực thể này là con của phần tử phiên giao dịch của thông điệp yêu cầu.

6. Chỉ số Ngoại lệ GDSN (GDSNException) PHẢI tương ứng với chỉ số thông điệp của thông điệp yêu cầu.

. Phần tử Chỉ số tạo lập duy nhất (uniqueCreatorIdentification) và phần tử Chủ sở hữu nội dung (contentOwner) là con của phần tử Định danh thông điệp ban đầu trong một Ngoại lệ GDSN (GDSNException) PHẢI được sao chép từ phần tử Chỉ số tạo lập duy nhất và phần tử Chủ sở hữu nội dung mà chúng là con của phần tử Chỉ số thực thể. Chỉ số thực thể lại là con của phần tử thông điệp của thông điệp yêu cầu.



7. Phản hồi đăng ký mặt hàng theo catalog (CatalogItemRegistrationResponse): Chỉ số của phản hồi PHẢI tương ứng với chỉ số tài liệu của thông điệp yêu cầu.

. Phần tử Chỉ số tạo lập duy nhất (uniqueCreatorIdentification) và phần tử Chủ sở hữu nội dung (contentOwner) đều là con của phần tử Tài liệu nhận được (documentReceived) / Chỉ số phản hồi (responseIdentification) trong một Phản hồi Đăng ký mặt hàng theo catalog xác thực PHẢI được sao chép từ phần tử Chỉ số tạo lập duy nhất và phần tử Chủ sở hữu nội dung, mà những phần tử này lại là con của phần tử Chỉ số thực thể (entityIdentification) – là con của phần tử tài liệu của thông điệp yêu cầu.

8. Phản hồi đăng ký thành viên (PartyRegistrationResponse): Chỉ số phản hồi PHẢI tương ứng với chỉ số tài

liệu của thông điệp yêu cầu.

. Phần tử Chỉ số tạo lập duy nhất (uniqueCreatorIdentification) và phần tử Chủ sở hữu nội dung (contentOwner) đều là con của phần tử Tài liệu nhận được (documentReceived) / Chỉ số phản hồi (responseIdentification) trong một Phản hồi Đăng ký mặt hàng theo catalog xác thực PHẢI được sao chép từ phần tử Chỉ số tạo lập duy nhất và phần tử Chủ sở hữu nội dung, mà những phần tử này lại là con của phần tử Chỉ số thực thể (entityIdentification) – là con của phần tử tài liệu của thông điệp yêu cầu.

9. Các giá trị của Người gửi và Người nhận của EANUCCResponse và GDSNException PHẢI so khớp với giá trị của Người gửi và Người nhận đã có trong SBDH của thông điệp yêu cầu.

10. Ngoại lệ thông điệp (MessageException) PHẢI được trả về khi có một hay nhiều lỗi được phát hiện ra trong quá trình xử lý SBDH và / hoặc xử lý phần tử thông điệp. Trong các trường hợp khác, Ngoại lệ phiên giao dịch (TransactionException) PHẢI được trả về.

11. Ngoại lệ GDSN (GDSNException) CÓ THỂ được trả về ở lần xuất hiện lỗi đầu tiên trong tài liệu đầu tiên

mà quá trình xử lý gặp lỗi như là một phần của phiên giao dịch đặc biệt. Điều này có nghĩa là người nhận thông điệp yêu cầu CÓ THỂ dừng xử lý phiên giao dịch đặc biệt đang gặp lỗi này ngay sau khi lỗi đầu tiên được phát hiện ra.

12. Người nhận được thông điệp yêu cầu NÊN trả về số lượng GDSNExceptions tương ứng với số lượng các lỗi phát hiện ra trong quá trình xử lý thông điệp bất kể các lỗi này ở các mức độ khác nhau (thông điệp, phiên giao dịch, câu lệnh, …).

13. Người nhận được thông điệp yêu cầu NÊN trả về GDSNExceptions ở mức độ thấp nhất mà tại đó lỗi xảy ra.

6.5. Các định danh trong GDSN

6.5.1. Chỉ số thực thể

GLN và GTIN được sử dụng để nhận biết các bên tham gia và các mặt hàng thương mại trong GDSN một cách tổng thể. Như đã giải thích trong sách Hướng dẫn kỹ thuật XML, một khái niệm tương tự được sử dụng để nhận biết các thông điệp, các giao dịch, các câu lệnh, v.v…

Cấu trúc được sử dụng cho mục đích này được gọi là Chỉ số Thực thể (EntityIdentification); Dưới đây là định nghĩa kiểu phức lược đồ XML hiện thời cho EntityIdentification:

<xsd:complexType name="EntityIdentificationType">

<xsd:sequence>

<xsd:element name="uniqueCreatorIdentification">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:maxLength value="80"I>



<xsd:minLength value="1"I>

<Ixsd:restriction>

<Ixsd:simpleType>

<Ixsd:element>

<xsd:element name="contentOwner" type="eanucc:PartyIdentificationType">

<Ixsd:element>

<Ixsd:sequence>

<Ixsd:complexType>

Như đã thấy trong đoạn các câu lệnh này, EntityIdentification gồm có GLN của chủ sở hữu nội dung và định danh duy nhất của chủ sở hữu nội dung. Chủ sở hữu nội dung được coi như là một Bên tham gia, và như đã đề cập trước đây, trong tổ chức GDSN chỉ số PHẢI được đảm bảo bằng cách thúc đẩy việc sử dung GLN. Chủ sở hữu nội dung PHẢI đảm bảo rằng định danh được tạo ra là duy nhất cho mỗi thực thể trong tên miền (domain) của chủ sở hữu. Việc kết hợp giữa GLN và định danh duy nhất tạo nên EntityIdentification tổng thể duy nhất.

6.5.2. Các quy tắc đối với các định danh GDSN

Dưới đây là các quy tắc cần phải tuân theo khi tạo lập các định danh trong GDSN:

■ Định danh thông điệp (là sự kết hợp của SBDH.Sender.Identifier và SBDH.DocumentIdentification.InstanceIdentifier) PHẢI là tổng thể duy nhất và PHẢI KHÔNG được sử dụng lại với các thông điệp khác.

Chú ý: Việc giải thích kỹ hơn ý nghĩa của từ “sử dụng lại” trong quy tắc nói trên là rất quan trọng. “Sử dụng

lại” ám chỉ trường hợp khi hai thông điệp khác nhau (với mục đích, nội dung, … khác nhau) lại ngẫu nhiên có cùng chỉ số. Điều này không được phép xảy ra. Nói cách khác, có những trường hợp có thể dẫn đến tình huống người gửi sẽ “gửi lại” thông điệp ban đầu; đã được đề cập trong Mục 5.1. Giao thức truyền thông. Trong trường hợp này, nội dung của toàn bộ thông điệp cần phải giống hệt với thông điệp ban đầu, dẫn đến chỉ số của thông điệp gửi lại này cũng giống với của thông điệp ban đầu.

■ Các thuộc tính sau đây, khi đi cùng nhau, PHẢI là duy nhất để ngăn chặn việc nhân bản tài liệu và gia tăng

việc truy tìm nguồn gốc trong GDSN:

Người gửi (Dữ liệu Dùng chung hoặc Đăng ký Toàn cầu) GLN / SBDH.DocumentIdentification.InstanceIdentifier/ Chỉ số Phiên giao dịch (Transaction ID) / Chỉ số Câu lệnh (Command ID) / Chỉ số tài liệu (Document ID).

Ví dụ:

■ Nếu sử dụng cùng Chỉ số Tài liệu trong cùng Câu lệnh, phiên giao dịch CÓ THỂ bị lỗi bởi Dữ liệu Người nhận Dùng chung.

■ Nếu sử dụng cùng Chỉ số Dòng lệnh trong cùng phiên giao dịch, phiên giao dịch đó CÓ THỂ bị lỗi bởi Dữ liệu Người nhận Dùng chung.

■ Nếu sử dụng cùng Chỉ số Phiên giao dịch trong cùng thông điệp, thông điệp đó CÓ THỂ bị lỗi bởi Dữ liệu Người nhận Dùng chung.

■ Một Dữ liệu Người nhận Dùng chung CÓ THỂ gặp lỗi với bất kỳ thông điệp nào từ Dữ liệu Người gửi Dùng chung nếu Dữ liệu Người gửi Dùng chung đã gửi trước đó đã gửi tới Dữ liệu Người nhận Dùng chung một thông điệp sử dụng cùng SBDH.DocumentIdentification.InstanceIdentifier.

6.6. Tiêu chuẩn với Phiên giao dịch, Câu lệnh và Tài liệu

Khi truyền đi các phiên giao dịch, các câu lệnh hay các tài liệu trong GDSN, việc sử dụng 3 phần tử này phải tuân theo một quy ước nhất quán. Nhìn từ góc độ kinh doanh, có một sự khác biệt giữa ngữ nghĩa hợp lệ về ngữ pháp và cú pháp với tài liệu cụ thể XML GS1 đã phê chuẩn và tiêu chuẩn mong muốn. Phần này mô tả cách sử dụng các phiên giao dịch, các câu lệnh và các tài liệu trong GDSN.



Chú ý: “Thông điệp” trong các quy tắc sau đây biểu thị Lớp Thông điệp (eanucc:message element) nằm

trong Tài liệu Kinh doanh Tiêu chuẩn. Các giới hạn áp dụng khi gửi thông điệp trong GDSN:

1. Giới hạn 1 Thông điệp trong một Tài liệu Kinh doanh Tiêu chuẩn

2. Giới hạn 1 kiểu tài liệu trong 1 Thông điệp

3. Giới hạn 100 Giao dịch trong 1 Thông điệp

4. Giới hạn 1 lệnh trong 1 Phiên giao dịch

5. Giới hạn 100 Tài liệu trong 1 Phiên giao dịch

6. Việc thực thi các câu lệnh và các tài liệu có thể theo các dạng:

□ Bao trùm tất cả các tài liệu trong 1 câu lệnh

□ Bao gồm cặp câu lệnh / tài liệu nhiều lần

Nếu một kho dữ liệu nhận được một thông điệp mà không tuân theo các giới hạn nói trên, Dữ liệu Người nhận Dùng chung CÓ THỂ từ chối thông điệp này và gửi đi một Ngoại lệ GDSN.

Chú ý: Khi có một số hiểu nhầm đối với Party Dump về mặt chức năng giữa hệ thống Đăng ký Toàn cầu

và các Dữ liệu Dùng chung, người ta nói đến Party Dump là một tệp (file) và không phải là một thông điệp GDSN. Hiểu theo cách thông thường, nó không bị hạn chế bởi các giới hạn nói trên.

6.7. Chủ sở hữu nội dung (Content Owner)

Trong các Dữ liệu Dùng chung GDSN cần nhất quán trong việc populating chủ sở hữu nội dung của một thông điệp với các mức thông điệp, phiên giao dịch, câu lệnh và tài liệu. Quy tắc sau đây là bắt buộc đối với mọi thông điệp GDSN:

■ Giá trị GLN của contentOwner ở mức thông điệp là GLN của Dữ liệu Dùng chung / Đăng ký Toàn cầu. Giá trị GLN của contentOwner ở các mức phiên giao dịch, câu lệnh và tài liệu là GLN của Nguồn dữ liệu / Người nhận dữ liệu.

6.8. Mã hóa ngôn ngữ

Mã hóa ngôn ngữ được sử dụng trong phiên bản GDSN 2.1 được biểu diễn như phần tử languageISOCode theo kiểu phức ISO639CodeType trong tệp Description.xsd.

<xsd:complexType name="ISO639CodeType">

<xsd:sequence>

<xsd:element name="languageISOCode">

<xsd:simpleType>

<xsd:restriction base="xsd:string">

<xsd:maxLength value="5"I>

<xsd:minLength value="1"I>

<Ixsd:restriction>

<Ixsd:simpleType>

<Ixsd:element>

<Ixsd:sequence>

<Ixsd:complexType>

Mặt khác, với các mã ngôn ngữ hợp lệ đòi hỏi thêm cú pháp sau:

aa{-BB}

Trong đó:



■ aa = danh sách mã ISO 639-1, 2- biểu diễn ký tự, với tùy chọn là chữ thường ■ BB = danh sách mã ISO 3166-1, 2- biểu diễn ký tự, dạng chữ hoa

Hai vị trí đầu tiên của languageISOCode PHẢI là mã ngôn ngữ hợp lệ từ mã ISO 639-1, (tức là: "en", "ru", "zh") và chúng PHẢI là chữ thường. Nếu một mã ngôn ngữ quốc gia đặc biệt muốn thêm vào dấu nối (“-“) tiếp theo là hai ký tự mã quốc gia từ danh sách mã ISO 3166-1 thì chúng (2 từ sau dấu (“-“)) phải ở dạng chữ hoa.

Ví dụ với những mã hóa ngôn ngữ chính xác

■ “en”

■ “ru”

■ “zh”

■ “zh-CN”

■ “zh-TW ”

Ví dụ với những mã hóa ngôn ngữ không chính xác

■ “EN”

■ “tw”

■ “zh-”

■ “zh-cn”

■ “ZH-TW ”

■ “ZH-tw”

■ “en840”

■ “en826”

■ “826”

6.9. Định dạng thời gian và ngày tháng

Hiện tại, trong lược đồ XML GDSN có những vị trí khác nhau mà các phần tử dữ liệu là kiểu dữ liệu “xsd:dateTime”. Mẫu của phần tử dữ liệu mà là kiểu dữ liệu xsd:dateTime PHẢI tuân theo một trong hai phương pháp sau đây (để buộc định dạng này thành các phần tử dữ liệu):

1. Thời gian CÓ THỂ được biểu thị ở dạng giờ quốc tế UTC (Coordinated Universal Time), với một chỉ định UTC (“Z”), hoặc

2. Thời gian CÓ THỂ được biểu thị ở dạng thời gian địa phương với thời gian theo múi giờ ở dạng giờ:phút (“+hh:mm” với thời gian vượt trước giờ quốc tế UTC và “-hh:mm” với thời gian chậm hơn giờ quốc tế UTC.

Ví dụ về Thời gian ngày tháng chính xác:

■ “2006-05-15T05:37:39-05:00” – tương đương với 15-05-2006, 5:37:39 sáng, Đông Mỹ

■ Thời gian chuẩn

■ “2006-05-15T10:37:39Z” – Vẫn là thời gian của ví dụ trên ở dạng giờ quốc tế UTC nhưng viết sai

■ “2006-05-15T05:37:39” – Thiếu chỉ báo khoảng thời gian bù thêm.

Chú ý: Có một số phần tử GDSN được biểu thị ở dạng xsd:date (không có thời gian). Điều này có thể là vấn

đề khi các thông điệp được gửi giữa các bên tham gia mà có múi giờ khác nhau.

6.10. Các Thông điệp tùy chọn, các Thuộc tính tùy chọn và các Mở rộng tùy chọn

Trong GDSN, các Dữ liệu Dùng chung có thể chọn lựa khi phản hồi với các thông điệp tùy chọn và các thông điệp có chứa các thuộc tính tùy chọn hay các mở rộng tùy chọn. Quy tắc sau đây là bắt buộc với các thông điệp GDSN này.



1. Các Dữ liệu Dùng chung và hệ thống Đăng ký Toàn cầu PHẢI KHÔNG gây lỗi (thông điệp ngoại lệ GDSN) cho một thông điệp GDSN chỉ duy nhất do tình trạng của một thuộc tính tùy chọn hay một mở rộng chính xác.

□ Nếu như nội dung của Mở rộng Cặp Giá trị Thuộc tính (AVP), và / hoặc Các thuộc tính Mở rộng không được hỗ trợ, Người nhận và / hoặc trách nhiệm của Dữ liệu Người nhận Dùng chung để bỏ qua những nội dung này. Có thể hiểu là Nguồn dữ liệu không yêu cầu sửa đổi thông điệp để đáp ứng bất kỳ chú thích đang xem xét khi cùng một mặt hàng có thể được gửi tới người nhận khác mà họ có thể xử lý những nội dung này.

2. Dữ liệu Người nhận Dùng chung CÓ THỂ gây lỗi (thông điệp ngoại lệ GDSN) cho các thông điệp tùy chọn trong mạng lưới không được hỗ trợ bởi Dữ liệu Người nhận Dùng chung. Một lỗi ngoại lệ GDSN mới mã hóa “thông điệp không được hỗ trợ” sẽ được tạo lập cho tình huống này.

3. Nếu có một phương pháp thiết thực để sử dụng lược đồ phiên bản sản phẩm để gửi dữ liệu đã chuẩn hóa, dữ liệu này không nên được gửi đi theo phương pháp nhân bản hay bổ sung với một mở rộng Cặp Giá trị Thuộc tính (AVP).

6.11. Các mở rộng GDSN – Trường hợp đơn / Cùng phần mở rộng

Trong GDSN, khi các Dữ liệu Dùng chung gửi các mở rộng nhờ phương pháp tiêu chuẩn, có một giới hạn để chỉ có một trường hợp cùng phần mở rộng trong bất cứ một thông điệp nào đó

Các quy tắc bắt buộc đối với các thông điệp GDSN loại này:

1. Các Dữ liệu Dùng chung PHẢI KHÔNG gây lỗi (thông điệp ngoại lệ GDSN) cho một thông điệp GDSN chỉ do tình trạng của một trường hợp mở rộng chính xác.

2. Dữ liệu Người nhận Dùng chung CÓ THỂ gây lỗi (thông điệp ngoại lệ GDSN) cho một thông điệp GDSN trong mạng lưới, nơi có nhiều hơn trường hợp phần mở rộng giống nhau.

6.12. Các thuộc tính đối kháng

Trong quá trình phát triển các tiêu chuẩn, các thuộc tính có thể trở nên lỗi thời hay kết hợp với các thuộc tính khác để tạo ra nhiều hơn các bổ sung linh hoạt để hỗ trợ cho một cộng đồng rộng lớn các sản phẩm.

Do đó, trong một phiên bản GDSN, một thuộc tính có thể đối kháng với dịch vụ, hoặc thường thì một thuộc tính có thể được đưa vào trong bổ sung tiêu chuẩn mở rộng.

Ví dụ phổ biến về một thuộc tính được đưa vào trong bổ sung tiêu chuẩn mở rộng là trong sự chuyển hướng một tập các thuộc tính có tính “công nghiệp đặc thù” để trở thành một bổ sung “công nghiệp không có tính chất rõ rệt”. Khi điều này sảy ra, tất cả các thuộc tính cũ và mới có thể cùng tồn tại tự nhiên trong các lược đồ. Trong trường hợp như vậy, khi mà thuộc tính cũ được xem như là lỗi thời, nó có thể vẫn ở đó tự nhiên mà không gây lỗi.

Các phần sau đây chỉ ra những thỏa thuận chính giữa các Dữ liệu Dùng chung GDSN xác thực về cách xử lý các tình huống hỗ trợ thuộc tính cụ thể khi liên quan đến các thuộc tính đối kháng:

6.12.1. Đối kháng do tính lỗi thời

Sự phân loại này định nghĩa một thuộc tính mà sẽ tồn tại không lâu sau khi được tạo ra. Mạng lưới không có yêu cầu nào khác để hỗ trợ thuộc tính này và nó được xem như còn liên quan trong thời gian rất ngắn.

Từ khi phần tử lược đồ thành phần không thể loại bỏ cho đến khi một phần tử ưu việt hơn được tạo ra, lược đồ này vẫn cho thấy thuộc tính với lượng thời gian đã định. Trong trường hợp này, các Dữ liệu Dùng chung phải rất nhanh chóng gửi thuộc tính này vào trong mạng lưới.

6.12.2. Đối kháng do Tiêu chuẩn hóa hoặc do sự nâng cấp

Sự phân loại này định nghĩa một thuộc tính khác mà việc thi hành ban đầu là được chuẩn hóa hiện tại (ví dụ, một Thuộc tính Mở rộng chuyển vào Tiêu chuẩn), hoặc một thuộc tính sẽ được chuyển từ một phần mở rộng có tính công nghiệp đặc thù thành một tập các thuộc tính lõi có tính công nghiệp không có tính chất rõ rệt phổ biến.

Dưới trường hợp này, việc bổ sung ban đầu với thuộc tính, không chú ý tới vị trí trong tài liệu GDSN, sẽ thay đổi theo chức năng và / hoặc chuyển đổi một cách vật lý tới khu vực có thể tiếp cận nhiều hơn của tài liệu GDSN.

Từ khi các phần tử lược đồ thành phần không thể loại bỏ cho đến khi một phần tử ưu việt hơn được tạo ra, lược đồ này vẫn cho thấy thuộc tính trong cả vị trí cũ cũng như ở vị trí mới. Sự bổ sung kép này thường dẫn đến nhầm



lẫn, cái giá phải trả cho việc bổ sung không cần thiết và chất lượng dữ liệu phát hành.

Đối với bất kỳ một thuộc tính đối kháng nào, chỉ bổ sung mới nhất mới nên truyền tải giữa các Dữ liệu Dùng chung để giảm chi phí và nhầm lẫn bên trong mạng lưới.

6.13. Hiệu lực Codelist

Quy tắc sau đây cho phép loại bỏ mã tùy chọn:

Người nhận có quyền (nhưng không phải nghĩa vụ) từ chối các giá trị với mọi thuộc tính mà một danh sách mã (codelist) tiêu chuẩn áp dụng, nếu giá trị đó trong yêu cầu không phải là thành phần của codelist áp dụng cho thuộc tính đó.

6.14. Định nghĩa phân loại

Quy tắc sau đây cho phép thiết lập định nghĩa việc phân loại Dữ liệu Dùng chung:

Giá trị cho Định nghĩa phân loại (classificationDefinition) có thể là định nghĩa Brick hoặc một phiên bản định nghĩa của Dữ liệu Dùng chung. Giá trị này nên chính xác nhưng không bắt buộc. Không có sự phê chuẩn nào đối với classificationDefinition tách biệt với hiệu lực bắt buộc của lược đồ.

7. Duy trì tài liệu Để các Dữ liệu Dùng chung GDSN đã chứng thực lưu trữ các thông điệp thực sự gửi đi và nhận được (Chu kỳ lưu trữ tối thiểu - MAP) cần tuân thủ yêu cầu sau theo cách thức:

■ 12 tháng cho lưu lượng vào và ra trong một Dữ liệu Dùng chung được chứng thực GDSN.

□ Thông điệp lưu chuyển không cần phải được lưu trữ bởi Dữ liệu Người nhận Dùng chung (trên cơ sở yêu cầu Dữ liệu Dùng chung ban đầu được lưu trữ tới 12 tháng). Tuy nhiên, khi có bất cứ thông điệp phản hồi nào được gửi bởi Người nhận dữ liệu từ Dữ liệu Dùng chung của họ tới Dữ liệu Dùng chung ban đầu, thông điệp đăng ký ban đầu từ Người nhận dữ liệu sẽ được lưu trữ bởi Dữ liệu Dùng chung của họ; Giới hạn trong 12 tháng (MAP).

Ví dụ, Bắt đầu với ngày đầu tiên của tháng hiện tại trong năm trước đó, nên nếu ngày hôm này là 17/02/2010 thì Dữ liệu Dùng chung lưu trữ từ ngày 01/02/2009 tới ngày 17/02/2010. Nói cách khác, chu kỳ lưu trữ sẽ lưu ít nhất 12 tháng (đôi khi, suýt soát 13 tháng).

Bằng cách duy trì hạn định này đối với chu kỳ lưu trữ, tất cả các Dữ liệu Dùng chung được sắp xếp (theo thời gian).

8. Khả năng khắc phục sự cố (DR)

Hệ thống GDSN có khả năng khắc phục sự cố với các lỗi nghiêm trọng của các hệ thống GDSN. Quyết định đối với một tình huống khắc phục sự cố sẽ được thông tin qua nhiều kênh nhanh nhất có thể được.

Có hàng loạt các địa chỉ Giao thức Internet (IP) mà các Dữ liệu Dùng chung phải quan tâm thường xuyên để họ có thể hợp nhất với chúng vào trong bức tường lửa cục bộ của họ. Trong trường hợp Khắc phục sự cố GDSN, khi Tổ chức GDSN khai báo, mạng lưới sẽ cắt giảm đối với hệ thống DR, mà hiện tại ở tại một vị trí địa lý khác so với các Máy chủ chứa thành phẩm (Production Servers). Các truy cấp DNS sẽ thay đổi các địa chỉ IP này. Khi mà các địa chỉ IP này được cho phép trong các tường lửa tại các Dữ liệu Dùng chung, sẽ không có bất kỳ dịch vụ nào được chạy từ các trang DR (trừ khi một Dữ liệu Dùng chung thích hợp khởi động lại). Dưới đây là đường dẫn đến địa chỉ IP dùng chung mà chúng ta sẽ sử dụng cho máy chủ DR GNSN: http:IIwww.gs1.orgIdocsIgdsnIGDSN_Disaster_Recovery_Site_2010April09.pdf

Chú ý: Thông tin này chỉ được giới thiệu với các Dữ liệu Dùng chung được chứng thực, và thông tin này

được chứa trong Khu vực Hỗ trợ Dữ liệu Dùng chung được chứng thực mà có yêu cầu quyền truy cập.

9. Thực thi GPC và tích hợp trong GDSN in 9.1. Quá trình thực thi GPC trong GDSN

Phần này mô tả quá trình thực thi GPC trong GDSN. Quá trình này cũng ghi địa chỉ các bước ở đó một Đối tác Thương mại hay một Đối tác Giải pháp với tư cách là đại diện của Đối tác Thương mại không thể tìm thấy một mã GPC thích hợp. Để một Đăng ký Mặt hàng theo catalog được đăng ký thì Một mã PHẢI được hỗ trợ khi nó là bắt buộc trong mạng lưới:

http://www.gsl.orgidocsigdsnigdsn_disaster_recovery_site_20l0april09.pdf/



■ Mạng lưới sẽ xác nhận tính hợp lệ của các mã dựa vào danh sách các thành phẩm (list in Production) trong GDSN.

■ Các mã hợp lệ bao gồm bất kỳ mã GPC đã triển khai hoặc “99999999” là một mã tạm thời cho các phân đoạn chưa triển khai hoặc cho các sản phẩm mới mà không thích hợp với lược đồ hiện tại.

■ Mạng lưới sẽ không / không thể xác nhận tính hợp lệ nếu mã đó được sử dụng hợp lệ trong ngữ cảnh (Ví dụ, mã Brick là hợp lệ cho sản phẩm này).

■ Kiểu loại của mã được gán phụ thuộc vào quan hệ giữa các đối tác thương mại (TP) và các nhà cung cấp giải pháp (SP).

■ Các đối tác thương mại sẽ thực hiện mọi nỗ lực để tìm ra mã chính xác.

■ Nếu không thể tìm thấy mã chính xác này, họ phải sử dụng “99999999” cho đến khi một mã thích hợp khả dụng được tạo ra.

■ Bước tiếp theo là đưa ra một Yêu cầu Công việc (thông qua Quy trình Quản lý Tiêu chuẩn toàn cầu (GSMP)), giám sát tiến trình, và khi một mã thích hợp khả dụng được tạo ra thì cập nhật vào hệ thống.

Lược đồ GPC chỉ có thể tiến triển khi nhận được Yêu cầu Công việc. Mỗi một Yêu cầu Công việc được xử lý một cách riêng rẽ và do đó các nhóm công việc có thể tiến triển riêng biệt ở bất kỳ thời điểm nào. Đây là động lực đằng sau chiến lược phát hành các xuất bản phẩm GPC với số lượng phiên bản hạn chế. Mỗi xuất bản phẩm đều được đóng dấu ngày tháng.

Khi một sản phẩm đã được đăng ký, cập nhật để mã hóa phụ thuộc vào Đối tác Thương mại và/hoặc Nhà cung cấp Giải pháp bổ sung các thay đổi khi họ đã định rõ và công bố trong các bản tin Delta. GDSN có một quá trình để thực hiện cập nhật GPC trong mạng lưới. Điều này có nghĩa là Mã hóa Brick GPC sẽ không được triển khai trong GDSN ngay sau khi chúng được phát hành mà là theo chu kỳ xuất bản, thường là trong vòng 6 tháng của xuất bản phẩm.

9.2. Quy trình tích hợp GPC vào GDSN

Phần này mô tả quá trình tích hợp GPC và các mã GPC vào GDSN.

Dựa trên việc hoàn thành các ấn phẩm GPC (2 lần / 1 năm), Nhà cung cấp Dịch vụ GPC gửi cho GDSN 2 tệp:

■ Lược đồ XML – Một bản chụp đầy đủ tất cả các điểm nút có hiệu lực trong mọi tiêu chuẩn đã công bố trong Lược đồ GPC tại thời điểm phát hành. Tài liệu này có mục đích là cung cấp một tầm nhìn chính xác và toàn diện về những gì có trong Lược đồ GPC tại thời điểm phát hành.

■ Delta XML – Một tài liệu XML chứa đựng tất cả các thay đổi giữa ấn phẩm hiện tại với các ấn phẩm trước đây. Tài liệu này có mục đích là cho phép có thể thay đổi / cập nhật tự động tới dữ liệu GPC chứa trong GDSN.

GDSN sẽ tích hợp / xử lý tài liệu Delta XML này.

Delta XML nhận biết các thay đổi với Lược đồ GPC bằng cách phân định kiểu thay đổi sử dụng mã thay đổi và cấp thay đổi (Đoạn, Họ, Lớp, …):

■ Các Bản bổ sung: Giới thiệu một mã mới. Với mỗi Bản bổ sung, GDSN sẽ thêm các mã mới vào cơ sở dữ liệu của họ.

■ Các Bản sửa đổi: Khi mã KHÔNG thay đổi nhưng văn bản mô tả CÓ thay đổi VÀ định nghĩa KHÔNG thay đổi. Các mã GPC KHÔNG BAO GIỜ được sửa đổi và khi đã xóa đi thì sẽ không bao giờ được sử dụng lại. Nếu Brick liên quan có sự thay đổi định nghĩa đáng kể, quy trình thông thường là bổ sung các mã mới và xóa bỏ các mã cũ.

■ Đối với mỗi Bản sửa đổi, GDSN sẽ cập nhật các mô tả của các mã liên quan lên cơ sở dữ liệu của họ.

■ Đánh dấu để xóa: Các mã được đánh dấu để xóa vẫn còn là một phần của lược đồ GPC; tuy nhiên, các mã này không nên được sử dụng để mã hóa bất cứ mặt hàng nào vừa mới được đăng ký. Đây là bước 1 của quy trình có 2 bước để xóa các mã GPC. Ở ấn bản GPC tiếp theo, các mã GPC đã được ‘đánh dấu để xóa’ này sẽ trở thành ‘xóa vật lý’ (xóa vĩnh viễn). Một trong những hoạt động của Đăng ký Toàn cầu GS1 để hoàn tất phần còn lại của quy trình này là tạo ra 1 dữ liệu dùng chung bởi một bản ghi dữ liệu dùng chung của tất cả các mặt hàng và các đăng ký mua hàng mà hiện tại sử dụng các mã GPC đã được xác định là “đánh dấu để xóa”. Mục đích là sử dụng thời gian giữa các phiên bản để hiệu chỉnh các mặt hàng hoặc xóa các đăng ký có liên quan. Các mã GPC đã được đánh dấu để xóa này trở thành danh sách các mã sẽ bị ‘xóa vật lý’ trong ấn phẩm tiếp theo.



■ Xóa vật lý: Các mã vừa được xác định trở thành ‘đánh dấu để xóa’ trước đó trong ấn phẩm GPC trước đây chuyển sang ‘xóa vật lý’ từ các lược đồ GPC. Khi ấn phẩm này được triển khai thành Sản phẩm trong GDSN, việc xóa bỏ sẽ xẩy ra trong Đăng ký Toàn cầu GS1. Kết quả là, bất kỳ quy tắc hợp lệ nào dựa trên các Mã GPC sẽ không thể tham chiếu tới các mã đã bị xóa này. Là một phần của quá trình triển khai trong Đăng ký Toàn cầu GS1, bất kỳ mặt hàng nào còn lại hoặc đăng ký mua hàng còn lại nào trong Đăng ký Toàn cầu GS1 được thanh lọc để bất kỳ tham chiếu nào tới các mặt hàng này hay các đăng ký mua hàng này không còn tồn tại.

GDSN_2_7

Documents

Transcript of GDSN_2_7