Trang /
Tiêu chuẩn Quốc gia TCVN ISO/TS 20625:2005 Quy tắc tạo các tệp lược đồ XML
- Thuộc tính
- Nội dung
- Tiêu chuẩn liên quan
- Lược đồ
- Tải về
Lưu
Theo dõi văn bản
Đây là tiện ích dành cho thành viên đăng ký phần mềm.
Quý khách vui lòng Đăng nhập tài khoản LuatVietnam và đăng ký sử dụng Phần mềm tra cứu văn bản.
Báo lỗi
Đang tải dữ liệu...
Đang tải dữ liệu...
Tiêu chuẩn Việt Nam TCVN ISO/TS 20625:2005
Tiêu chuẩn Quốc gia TCVN ISO/TS 20625:2005 ISO/TS 20625:2002 Trao đổi dữ liệu điện tử trong hành chính, thương mại và vận tải (EDIFACT) - Quy tắc tạo các tệp lược đồ XML (XSD) trên cơ sở các hướng dẫn thực thi của EDI (FACT)
Số hiệu: | TCVN ISO/TS 20625:2005 | Loại văn bản: | Tiêu chuẩn Việt Nam |
Cơ quan ban hành: | Bộ Khoa học và Công nghệ | Lĩnh vực: | Thông tin-Truyền thông |
Ngày ban hành: | 17/02/2006 | Hiệu lực: | |
Người ký: | Tình trạng hiệu lực: | Đã biết Vui lòng đăng nhập tài khoản gói Tiêu chuẩn hoặc Nâng cao để xem Tình trạng hiệu lực. Nếu chưa có tài khoản Quý khách đăng ký tại đây! | |
Tình trạng hiệu lực: Đã biết
Ghi chú: Thêm ghi chú cá nhân cho văn bản bạn đang xem.
Hiệu lực: Đã biết
Tình trạng: Đã biết
TIÊU CHUẨN QUỐC GIA
TCVN ISO/TS 20625 : 2005
ISO/TS 20625 : 2002
TRAO ĐỔI DỮ LIỆU ĐIỆN TỬ TRONG HÀNH CHÍNH, THƯƠNG MẠI VÀ VẬN TẢI (EDIFACT) - QUY TẮC TẠO CÁC TỆP LƯỢC ĐỒ XML (XSD) TRÊN CƠ SỞ CÁC HƯỚNG DẪN THỰC THI CỦA EDI (FACT)
Electronic data interchange for administration, commerce and transport (EDIFACT) - Rules for generation of XML scheme files (XSD) on the basis of EDI (FACT) implementation guidelines
Lời nói đầu
TCVN ISO/TS 20625 : 2005 hoàn toàn tương đương với ISO/TS 20625: 2002.
TCVN ISO/TS 20625 : 2005 do Ban kỹ thuật tiêu chuẩn TCVN/TC 154 "Quá trình, các yếu tố dữ liệu và tài liệu trong thương mại, công nghiệp và hành chính" biên soạn, Tổng cục Tiêu chuẩn Đo lường Chất lượng trình duyệt, Bộ Khoa học và Công nghệ ban hành.
Tiêu chuẩn này được chuyển đổi năm 2008 từ Tiêu chuẩn Việt Nam cùng số hiệu thành Tiêu chuẩn Quốc gia theo quy định tại Khoản 1 Điều 69 của Luật Tiêu chuẩn và Quy chuẩn kỹ thuật và điểm a khoản 1 Điều 6 Nghị định số 127/2007/NĐ-CP ngày 1/8/2007 của Chính phủ quy định chi tiết thi hành một số điều của Luật Tiêu chuẩn và Quy chuẩn kỹ thuật.
Lời giới thiệu
Các tiêu chuẩn EDI về thương mại cung cấp một cú pháp dành cho sự thực thi nội dung dữ liệu trong các quá trình thương mại khác nhau thông qua việc sử dụng các phần tử dữ liệu, các đoạn và các kiểu thông điệp. XML ban đầu cung cấp một cú pháp khác hoàn toàn mà nếu sử dụng sẽ dẫn đến các chi phí mới khổng lồ, do đó ngăn chặn mục tiêu ban đầu - cho các doanh nghiệp vừa và nhỏ (SME) tham gia các quá trình thương mại điện tử.
Tiêu chuẩn này trình bày cách áp dụng bí quyết sản xuất EDI sẵn có cho cú pháp XML. Người sử dụng XML do đó có thể dễ dàng sử dụng dữ liệu EDI từ các ứng dụng sẵn có theo cách thích hợp.
Hướng dẫn thực thi thông điệp EDIFACT (Các MIG) trình bày sự thực thi các kiểu thông điệp EDIFACT đã được tiêu chuẩn hóa trong một quá trình nghiệp vụ. Do đó, các MIG là nguồn phù hợp cho việc rút ra lược đồ XML. Tiêu chuẩn này quy định quá trình truyền.
TRAO ĐỔI DỮ LIỆU ĐIỆN TỬ TRONG HÀNH CHÍNH, THƯƠNG MẠI VÀ VẬN TẢI (EDIFACT) - QUY TẮC TẠO CÁC TỆP LƯỢC ĐỒ XML (XSD) TRÊN CƠ SỞ CÁC HƯỚNG DẪN THỰC THI CỦA EDI (FACT)
Electronic data interchange for administration, commerce and transport (EDIFACT) - Rules for generation of XML scheme files (XSD) on the basis of EDI (FACT) implementation guidelines
1. Phạm vi áp dụng
Tiêu chuẩn này trình bày các quy tắc tạo lược đồ XML từ các hướng dẫn thực thi thông điệp EDI, cung cấp một phương pháp đúng đắn để biểu diễn các thực tế ngữ nghĩa.
Tiêu chuẩn này trình bày cách tạo ra XML từ các MIG UN/EDIFACT. Về nguyên tắc, các quy tắc này cũng có thể áp dụng tương tự cho các tiêu chuẩn EDI khác.
Tiêu chuẩn này không áp dụng cho các định nghĩa kiểu tài liệu (DTD).
2. Tài liệu viện dẫn
TCVN ISO 8601 : 2004 (ISO 8601 : 2000), Phần tử dữ liệu và dạng thức trao đổi - Trao đổi thông tin - Biểu diễn thời gian.
TCVN ISO 9735-1 : 2003 (ISO 9735-1 : 2002), Trao đổi dữ liệu trong hành chính, thương mại và vận tải (EDIFACT) - Quy tắc cú pháp mức ứng dụng (Số phiên bản cú pháp 4, Số phát hành cú pháp: 1) - Phần 1: Quy tắc cú pháp chung.
3. Thuật ngữ, ký hiệu và chữ viết tắt
Tiêu chuẩn này sử dụng các thuật ngữ, ký hiệu và các từ viết tắt sau đây:
3.1. BSR (Basic Semantics Register)
Bộ đăng ký ngữ nghĩa cơ sở.
3.2. BSU (Basic Semantic Unit)
Đơn vị ngữ nghĩa cơ sở.
3.3. DTD (Document Type Definition)
Định nghĩa kiểu tài liệu.
3.4. EDI (Electronic Data Interchange) Trao đổi dữ liệu điện tử.
3.5. EDIFACT (Electronic Data Interchange for Administration, Commerce and Transport)
Trao đổi dữ liệu điện tử trong quản lý hành chính, thương mại và vận tải.
3.6. PHẦN TỬ (Element)
Khối xây dựng cú pháp bao gồm dữ liệu và/ hoặc các thuộc tính.
3.7. HTML (Hyper Text Mark-up Language)
Ngôn ngữ đánh dấu siêu văn bản.
3.8. MIG (Message Implementation Guideline)
Hướng dẫn thực thi thông điệp.
3.9. TÊN (Name)
Một tên trong ngữ cảnh XML, bắt đầu bằng một chữ cái hoặc một ký tự đặc biệt được phép, tiếp theo là các chữ cái, chữ số, dấu nối, dấu gạch dưới, dấu hai chấm hoặc dấu chấm. Chúng được gọi là thẻ tên. Các tên bắt đầu với “xml” hoặc một sâu ký tự trùng với (('X'|'x') ('M'|'m') ('L'|'l') được dành cho việc tiêu chuẩn hóa XML.
3.10. SGML (Standard Generalised Mark-up Language)
Ngôn ngữ đánh dấu khái quát hóa tiêu chuẩn.
3.11. Thẻ (Tag)
Dạng thức lệnh hoặc đánh dấu ngữ nghĩa.
3.12. Khuôn mẫu (template)
Mẫu tham chiếu xác định trước được so sánh với thực thể hoàn chỉnh để được công nhận, hoặc một phần của nó.
3.13. XLL (Extensible Link Language)
Ngôn ngữ liên kết có thể mở rộng.
3.14. 6.1.1 XML (Extensible Mark-up Language)
Ngôn ngữ đánh dấu có thể mở rộng.
3.15. XSD (Extensible Schema Definition)
Định nghĩa lược đồ có thể mở rộng.
3.16. XSL (Extensible Stylsheet Language)
Ngôn ngữ tờ mẫu có thể mở rộng.
3.17. W3C (World Wide Web Consortium)
Một consortium công nghiệp quốc tế phát triển các giao thức chung để phát triển www.
4. Nội dung điển hình của hướng dẫn thực thi thông điệp
4.1. Mức: MIG
a) định danh MIG;
b) định danh việc hỗ trợ danh mục EDIFACT;
c) định danh kiểu thông điệp và các phân ngành công nghiệp, nếu cần thiết;
d) văn bản bổ sung.
4.2. Mức: Kiểu thông điệp
a) cấu trúc kiểu thông điệp (các nhóm đoạn và các đoạn) và sự chỉ định các phần được sử dụng của chúng;
b) trạng thái (tiêu chuẩn so với ứng dụng) của đoạn và nhóm đoạn khi sử dụng;
c) tên và các mô tả đoạn và nhóm đoạn liên quan đến ngữ cảnh;
d) ví dụ;
e) các phụ thuộc giữa đoạn và nhóm đoạn;
f) văn bản bổ sung, nhận xét về mức kiểu thông điệp.
4.3. Mức: Đoạn và phần tử dữ liệu hỗn hợp
a) cấu trúc đoạn và phần tử dữ liệu hỗn hợp và chỉ định các phần được sử dụng của chúng;
b) trạng thái (tiêu chuẩn so với áp dụng) của phần tử dữ liệu và phần tử dữ liệu hỗn hợp;
c) sự phụ thuộc giữa phần tử dữ liệu và phần tử dữ liệu hỗn hợp trong một đoạn và kiểu thông điệp;
d) tên và các mô tả liên quan đến ngữ cảnh;
e) ví dụ;
f) văn bản bổ sung, nhận xét.
4.4. Mức: Phần tử dữ liệu
a) đặc điểm các phần tử dữ liệu EDI (kiểu, độ dài) và giới hạn sử dụng của chúng dựa trên cơ sở MIG và sự thực thi liên quan đến ngữ cảnh;
b) tên và mô tả phần tử dữ liệu liên quan đến ngữ cảnh và các thẻ mô tả duy nhất, nếu cần thiết, ví dụ được tạo từ các kho dữ liệu như ISO - BSR (xem TCVN ISO/TS 16668);
c) các ví dụ;
d) văn bản bổ sung, các nhận xét;
e) các giá trị cho phép;
f) các hằng số;
g) các mã xác định của EDIFACT hoặc danh sách mã ISO/ UN được đưa ra một cách rõ ràng;
h) các mã xác định của người sử dụng định nghĩa được đưa ra một cách rõ ràng;
i) các mã xác định của EDIFACT không hoặc danh sách mã ISO/UN được đưa ra một cách ngầm hiểu;
j) các mã xác định của người sử dụng định nghĩa được đưa ra một cách ngầm hiểu hoặc các mã khác mà không được liệt kê trong danh mục mã EDIFACT;
k) các quy tắc để giá trị phần tử dữ liệu phải phù hợp;
l) việc ánh xạ tới các trường trong các ứng dụng và các tệp phẳng, theo thứ tự định sẵn.
5. Các yêu cầu của các qui tắc tạo lược đồ
a) thông tin kỹ thuật của MIG như được liệt kê trong đoạn 4 phải được hợp nhất vào các giản đồ khi cần thiết;
b) cấu trúc MIG cơ sở phải hiểu được (cả các hướng dẫn XML và EDI truyền thống phải tương thích về cấu trúc);
c) kết quả thông điệp XML càng đơn giản càng tốt;
d) một trong các biến thể khác nhau là do thực tế ngữ nghĩa có thể được biểu diễn trong XML được quy định là bắt buộc trong tiêu chuẩn này;
e) người xây dựng MIG quyết định dữ liệu là quan trọng và cấu trúc có nghĩa cho ứng dụng của họ. Lúc này, họ quyết định các phần tử cấu trúc phải được hợp nhất trong lược đồ đó.
6. Quy tắc tạo lược đồ XML từ các MIG EDI
CHÚ THÍCH: Tên miền ‘din’ trong các ví dụ của phần này chỉ để minh họa và có thể lược bỏ hoặc sử dụng bất kỳ tên miền phù hợp khác.
6.1. Quy tắc 1: Đặt tên thẻ
6.1.1. Biến thể 1
Các tên của cấu trúc XML được tạo ra từ các thẻ EDI. Chúng sẽ được đưa ra một tiền tố phụ thuộc vào mức cấu trúc (nhóm đoạn, đoạn, phần tử dữ liệu hỗn hợp hoặc phần tử dữ liệu):
“M_”+ kiểu thông điệp + [hậu tố] Ví dụ: M_ORDERS
“G_”+ nhóm đoạn + [hậu tố] Ví dụ: G_SG36 hoặc G_LIN_ALC
“S_”+ đoạn + [hậu tố] Ví dụ: S_LIN
“C_”+ phần tử dữ liệu hỗn hợp + [hậu tố] Ví dụ: C_C082_2
“D_”+ phần tử dữ liệu + [hậu tố] Ví dụ: D_3035 hoặc D_3035_10
Hậu tố là tùy chọn và có thể được tạo ra dựa vào cách hiểu ngữ nghĩa khác nhau của các phần tử EDI.
Nếu tệp lược đồ XML được tạo ra từ một MIG EDI EDIFACT thì chỉ cần tiền tố “D_”. Tuy nhiên, nếu các tiền tố khác phải được sử dụng bởi các tiêu chuẩn EDI xác định các phần tử dữ liệu hỗn hợp và phần tử dữ liệu bằng việc sử dụng các thẻ số thì chúng là bắt buộc.
Ký hiệu thứ hai của các thẻ nhóm đoạn có thể được sử dụng khi tiêu chuẩn EDI cơ sở được chuyển đổi từ các cung cấp các nhóm đoạn không rõ ràng hoặc bất kỳ khi nào ký hiệu này của các đoạn khởi tạo liên quan thích hợp hơn. Trong trường hợp này, sự lồng nhau của các nhóm đoạn phải được đưa ra theo thứ tự của các đoạn khởi tạo của chúng.
Khuyến cáo XML W3C yêu cầu các “thẻ tự giải thích”. Các thẻ EDI[FACT] hoàn thành điều kiện này tốt hơn các thẻ theo ngôn ngữ tự nhiên, bởi vì chúng biểu diễn một ngôn ngữ chung được thiết lập dành cho các chuyên gia EDI.
Ví dụ:
6.1.1. Biến thể 2
Từ các nhận xét phù hợp, các thẻ “nói” có thể được tạo ra nếu muốn. Nếu sử dụng thẻ “nói” thì gốc EDI của phần tử tương ứng phải được tài liệu hóa bằng một giá trị thuộc tính thích hợp (Xem phần 6.9) hoặc phương tiện tài liệu dẫn chứng khác.
Ví dụ:
6.2. Quy tắc 2: Cấu trúc
6.2.1. Các tên hoặc thẻ EDI giống nhau sẽ tạo ra các phần tử tập hợp (xem quy tắc 6.10).
6.2.2. Nếu mong muốn sự khác nhau giữa các lần xuất hiện ngữ nghĩa khác nhau của cùng bộ lưu trữ dữ liệu thì các tên hoặc thẻ khác nhau phải được ấn định bằng việc thêm vào một hậu tố bổ sung cho thẻ EDI hoặc sử dụng các tên khác nhau.
6.2.3. Lược đồ có thể bao gồm thêm các phần tử “dập ghim” đối với nhóm các thông điệp hoặc bản thân trao đổi đó (có thể so sánh với UNG - UNE và UNB - UNZ của UN/EDIFACT).
6.2.4. Một bộ lưu trữ dữ liệu EDI bất kỳ (kiểu thông điệp, nhóm đoạn, đoạn v.v.) có thể được coi như một phần tử XML độc lập. Cấu trúc EDI hiện tại là nguồn gốc của cấu trúc XML đó. Do đó, lược đồ XML phải có một cấu trúc tương thích với MIG của EDI. Tập phần tử XML được tạo ra là nhỏ hơn hoặc bằng tập các phần tử EDI.
CHÚ THÍCH: Phương thức tác giả viết một MIG phải thỏa mãn các nhu cầu về qui trình nghiệp vụ tương ứng. Do đó, lược đồ này phải được xây dựng phù hợp. Nếu trong ví dụ MIG bao gồm “ngày tháng lập tài liệu” và “ngày tháng yêu cầu phát” trong lần xuất hiện riêng biệt của đoạn DTM thì các phần tử XML phân biệt phải được tạo ra phù hợp với điều kiện ở trên. Nếu chúng được tài liệu hóa trong cùng lần xuất hiện của đoạn DTM thì chỉ một phần tử XML được tạo ra.
Ví dụ cho 6.2.1 và 6.2.2:
Biến thể 1:
Hướng dẫn này bao gồm hai đoạn DTM (xem hình 1)
Hình 1 - Sơ đồ thông điệp của một hướng dẫn bao gồm hai đoạn DTM
Chuyển dịch mặc định sang một lược đồ XML theo 6.2.1 như sau:
CHÚ THÍCH: Phần tử D_2005 là một kiểu liệt kê và bao gồm hai giá trị có thể ‘2’ và ‘4’.
Ngoài ra, áp dụng quy tắc 6.2.2 có kết quả là:
hoặc
Biến thể 2:
Hướng dẫn lập tài liệu ngày tháng ngầm hiểu có sử dụng chỉ một đoạn DTM (Xem hình 2).
Hình 2 - Sơ đồ thông điệp một hướng dẫn chỉ bao gồm một đoạn DTM
Chuyển dịch sang một lược đồ XML tương tự ví dụ trước theo quy tắc 6.2.1 như sau:
Ví dụ cho 6.2.3:
6.3. Quy tắc 3: Tối ưu hóa cấu trúc
Nếu cấu trúc XML phẳng là mối quan tâm chính, việc áp dụng các quy tắc sau sẽ đưa ra một kết quả tối ưu. Tuy nhiên, đối với sự tích hợp trong các hệ thống hiện tại, người ta phải quan tâm các yêu cầu cấu trúc dữ liệu nhỏ nhất được thiết lập bởi hệ thống EDI trong việc sử dụng hơn nữa là các yêu cầu cú pháp thuần tuý.
6.3.1. Một đoạn EDIFACT bao gồm hơn một phần tử dữ liệu với dữ liệu kinh doanh nghiệp vụ, trên thực tế có một chức năng khái quát hóa. Nếu đoạn đó chỉ bao gồm một phần tử dữ liệu với dữ liệu nghiệp vụ thì không có chức năng khái quát hóa trên mức đoạn. Do đó trong sự chuyển dịch sang lược đồ XSD mức đoạn này có thể không xuất hiện.
6.3.2. Các phần tử của tiêu chuẩn chính mà không được sử dụng trong MIG sẽ được lược bỏ.
6.3.3. Các hạn định hằng số hoặc mã hằng số không được chuyển đổi sang cấu trúc XML (đối với một phần tử dữ liệu xác định thì chỉ một mã được tài liệu hóa trong MIG). Các phần tử dữ liệu tương ứng không được chuyển đổi sang XML.
Ví dụ:
Được tạo ra từ:
Quy tắc này tạo ra:
Các mức đoạn và phần tử dữ liệu hỗn hợp không được yêu cầu khi chúng chỉ bao gồm các hạn định hằng số. Do đó chúng được lược bỏ.
6.4. Quy tắc 4: Trạng thái
Trạng thái EDI và trạng thái áp dụng trong MIG sẽ được khái quát hóa trong trạng thái XML. Trạng thái giới hạn hơn được giữ lại.
Trạng thái “bắt buộc” được biểu diễn bằng một hệ số lặp nhỏ nhất là “1”, trạng thái “điều kiện” bằng một hệ số lặp nhỏ nhất là “0”. Trạng thái được đưa ra bằng thuộc tính minOccurs.
Các ví dụ:
Điều kiện:
Nhóm đoạn | |
Đoạn | |
Phần tử dữ liệu hỗn hợp | |
Phần tử dữ liệu |
Bắt buộc:
Nhóm đoạn | |
Đoạn | |
Phần tử dữ liệu hỗn hợp | |
Phần tử dữ liệu |
6.5. Quy tắc 5: Số lần xuất hiện lớn nhất
Số lần xuất hiện mà MIG tạo ra lần xuất hiện XML. Giá trị được cung cấp qua thuộc tính XSD maxOccurs.
Ví dụ:
Nhóm đoạn | |
Đoạn |
Từ phiên bản cú pháp số 4 của EDIFACT (TCVN ISO 9735-1) và việc thực thi các danh mục thích hợp, quy tắc lần xuất hiện có thể áp dụng với phần tử dữ liệu hỗn hợp và phần tử dữ liệu.
6.6. Quy tắc 6: Các dạng thức của phần tử dữ liệu
6.6.1. Biểu diễn “chữ số” (“an”) và “chữ” (“a”) thành “chuỗi ký tự” (“string”), “số” (“n”) thành “số thập phân” (“decimal”). Đối với độ dài các phần tử dữ liệu số và chữ số được định nghĩa trong MIG, các kiểu dữ liệu đơn giản (simpleType) thích hợp sẽ được tạo ra.
6.6.2. Các dạng thức ngày tháng có thể được chuyển dịch vào các kiểu dữ liệu XML “ngày tháng” (“date”), “thời gian tức thời” (“timeInstant”) và “thời gian” (“time”). Trong trường hợp này, yêu cầu một sự chuyển đổi dạng thức. Sự biểu diễn các dạng thức này trong XML là:
Ngày tháng (date): | |
Thời gian (time): | |
Thời gian tức thời (timeInstant): |
Ví dụ:
6.7. Quy tắc 7: Danh sách mã và mã do người sử dụng định nghĩa
6.7.1. Các phần tử dữ liệu mã hóa được định nghĩa là kiểu phức (complexType). Nếu đối với một phần tử dữ liệu, chỉ các mã đặc trưng được tài liệu hóa trong MIG thì chỉ các mã này là được phép áp dụng. Do đó, chỉ các mã này được chuyển dịch vào cấu trúc XML.
6.7.2. Nếu MIG không cung cấp mã cho một phần tử dữ liệu thì danh sách mã có hiệu lực đầy đủ là được phép. Danh sách mã đầy đủ này sẽ được chuyển đổi sang cấu trúc XML.
6.7.3. Danh sách mã được sử dụng lặp lại có thể được cung cấp bằng việc sử dụng các tệp ngoài.
6.7.4. Tên mã sẽ được lưu trữ tùy chọn như phần chú thích cùng với mã.
6.7.5. Theo quy tắc 3 (xem phần 6.3) các mã hằng số hoặc các hạn định hằng số sẽ không được chuyển đổi sang cấu trúc XML (đối với một phần tử dữ liệu cụ thể chỉ một mã được tài liệu hóa trong MIG). Các phần tử dữ liệu tương ứng không cần được cung cấp trong cấu trúc XML. Tuy nhiên, nếu việc sử dụng một phần tử dữ liệu được yêu cầu rõ ràng, nó phải bao gồm trong cấu trúc XML (như là; một phần tử dữ liệu đang sử dụng hiện hành 6345 trong đoạn MOA).
Ví dụ:
(1)
(2)
(3)
(4)
(5)
6.8. Quy tắc 8: Các tên của đối tượng EDI
6.8.1. Tên được định nghĩa bởi người sử dụng hoặc được tiêu chuẩn hóa của nhóm đoạn, đoạn, phần tử dữ liệu hỗn hợp và phần tử dữ liệu có thể được cung cấp như thuộc tính “chú thích” trong lược đồ. Chỉ một tên EDI được cho phép như một thuộc tính cho một phần tử XML bất kỳ.
6.8.2. Nếu có cả tên định nghĩa bởi người sử dụng và được tiêu chuẩn hóa cho một đối tượng EDI thì chỉ giữ lại tên định nghĩa bởi người sử dụng.
CHÚ THÍCH: Câu cuối cùng đề cập đến tên một đối tượng mà có thể được nhận thấy như tên do người sử dụng định nghĩa, BSU hoặc tương tự trong các MIG. Theo cách này, tệp XML ánh xạ logic và rút gọn có thể dễ dàng sử dụng một bộ phân tích cú pháp.
Ví dụ:
(1)
(2)
6.9. Quy tắc 9: ánh xạ các chi tiết
6.9.1. Đến mức MIG bao gồm các chi tiết ánh xạ, “điểm neo” có thể được tạo như các thuộc tính. Chúng phải cho phép thực thi dễ dàng một dạng thức trao đổi XML trong các hệ thống EDI phụ.
6.9.2. Nguồn EDI[FACT] được cung cấp bằng việc sử dụng thuộc tính “nguồn EDI”. Các ký hiệu này kết hợp chức năng thực thi tư liệu với thông tin cơ sở của một phiên bản phát hành danh mục - ví dụ danh mục EDIFACT.
Áp dụng các quy tắc sau đây:
- đường dẫn được chỉ định dưới dạng “nhóm đoạn, đoạn, phần tử dữ liệu hỗn hợp, phần tử dữ liệu” hoặc “nhóm đoạn, đoạn, phần tử dữ liệu”.
- nhóm đoạn có thể xuất hiện nhiều lần để chỉ các mức của cấu trúc EDI[FACT].
- trong trường hợp đa biến thể ngữ nghĩa việc hạn định nhóm đoạn của các nhóm đoạn thì hạn định của nó và giá trị tương ứng của hạn định đó nên được đặt trong ngoặc vuông.
Tại cuối số thứ tự của đoạn được đưa ra trong kiểu thông điệp EDIFACT gốc được bổ sung số thứ tự phần tử dữ liệu (phần tử dữ liệu hỗn hợp hoặc phần tử dữ liệu thường) trong đoạn tương ứng sau dấu hai chấm và nếu thích hợp, cả số thứ tự phần tử dữ liệu thành phần trong một phần tử dữ liệu hỗn hợp.
Ví dụ, ký hiệu (0120 : 020 : 02) được đọc như sau: “Số thứ tự của đoạn trong tiêu chuẩn” : “số thứ tự phần tử dữ liệu hỗn hợp hoặc phần tử dữ liệu” : “số thứ tự phần tử dữ liệu thành phần trong phần tử dữ liệu hỗn hợp nếu thích hợp”.
Các ví dụ:
(1)
(2)
6.10. Quy tắc 10: Tập hợp của bộ lưu trữ dữ liệu cùng tên
Nếu có các kịch bản thực thi với các kiểu thông điệp khác nhau và người sử dụng muốn tập hợp bộ lưu trữ dữ liệu cùng tên và mô tả chúng trong kịch bản duy nhất thì áp dụng các quy tắc sau:
6.10.1. Cấu trúc
Các bộ lưu trữ dữ liệu tập hợp bao gồm tất cả phần tử phụ tối thiểu được sử dụng và tài liệu hóa trong hướng dẫn thực thi thông điệp. Thứ tự các phần tử đó phải tuân theo thứ tự được đưa ra trong Tiêu chuẩn - EDI.
6.10.2. Trạng thái
Trong một bộ lưu trữ dữ liệu tập hợp thì trạng thái phần tử phụ phải là tùy chọn nếu phần tử phụ này được sử dụng tùy ý ngay trong bộ lưu trữ dữ liệu theo câu hỏi trong toàn bộ kịch bản của thông điệp.
Ví dụ: ORDERS DTM 2379 trạng thái: R, IFTMIN DTM 2379 trạng thái: O
→ Trạng thái XML: O.
6.10.3. Dạng thức
Dạng thức xác định theo dạng thức được sử dụng rộng rãi nhất được quy định trong các hướng dẫn thực thi thông điệp.
Ví dụ: Dạng thức của ORDERS DTM 2380: n8, dạng thức của IFTMIN DTM 2380: an..35
→ Dạng thức của XML: chuỗi1..35.
6.10.4. Danh sách mã
Đối với mỗi phần tử dữ liệu mã hóa thì một danh sách mã tập hợp phải được tạo ra để bao gồm tất cả mã có thể áp dụng theo hướng dẫn thực thi thông điệp.
Ví dụ: Danh sách mã của ORDERS DTM 2380: 102; 103, danh sách mã của IFTMIN DTM 2380: 103; 203
→ Danh sách mã XML: 102; 103; 203.
Phụ lục A
(tham khảo)
Ví dụ ánh xạ từ EDIFACT tới XML
CHÚ THÍCH: Vì các lý do thực tế, ví dụ được trình bày trong phụ lục này dựa trên cơ sở các thẻ nói theo Tiếng Đức. Tuy nhiên, nó không loại trừ việc sử dụng các ngôn ngữ khác. Trạng thái R nghĩa là “yêu cầu” còn trạng thái O nghĩa là “tùy chọn”. Cả hai trạng thái đều là thông tin trạng thái áp dụng và có nghĩa như M (bắt buộc) và C (điều kiện). Trạng thái N nghĩa là “không sử dụng”.
A.1. Cấu trúc EDIFACT cơ bản cho ánh xạ
A.1.1. Khái quát
Cơ sở cấu trúc XML được tạo ra là việc thực thi kiểu thông điệp EDIFACT đơn đặt hàng (đơn đặt hàng mua bán) với các chi tiết như sau.
A.1.2.1. Bảng đoạn
Bảng A.1 - Bảng đoạn đơn đặt hàng (ORDERS) của EDIFACT cơ bản
| Số | Thẻ | Trạng thái | Lặp lại | Nội dung |
| 01 | UNH | M | 1 | Tiêu đề thông điệp |
| 02 | BGM | M | 1 | Kiểu tài liệu và số hiệu |
| 03 | DTM | M | 1 | Ngày tháng đặt hàng |
| 04 | DTM | M | 1 | Ngày tháng phân phối |
|
| SG2 | R | 1 | Người mua |
| 05 | NAD | M | 1 | Định danh người mua |
| 06 | FII | O | 1 | Thông tin tài khoản ngân hàng của người mua |
|
| SG3 | O | 1 | Số hiệu VAT của người mua |
| 07 | RFF | M | 1 | Số hiệu VAT |
|
| SG5 | O | 1 | Thông tin liên hệ người mua |
| 08 | CTA | M | 1 | TƯ cách pháp nhân người mua |
| 09 | COM | O | 1 | Số điện thoại |
| 10 | COM | O | 1 | Liên lạc thông tin |
|
| SG2 | R | 1 | Người bán |
| 11 | NAD | M | 1 | Định danh người bán |
|
| SG7 | O | 1 | Tiền tệ |
| 12 | CUX | M | 1 | Tiền tệ theo đơn hàng |
|
| SG25 | R | 10 | Hạng mục dòng |
| 13 | LIN | M | 1 | Số hiệu hàng của nhà cung cấp |
| 14 | IMD | O | 1 | Mô tả sơ lược về sản phẩm |
| 15 | QTY | O | 1 | Số lượng được đặt hàng |
| 16 | MOA | O | 1 | Tổng hạng mục dòng |
|
| SG27 | O | 1 | Giá của hạng mục |
| 17 | PRI | M | 1 | Giá của mỗi hạng mục/ đơn vị |
| 18 | UNS | M | 1 | Kiểm soát phần |
| 19 | MOA | R | 1 | Tổng giá trị |
| 20 | UNT | M | 1 | Đuôi thông điệp |
A.1.2.2. Sơ đồ cấu trúc thông điệp
Hình A.1 - Sơ đồ cấu trúc thông điệp (Sơ đồ nhánh) Đơn đặt hàng (ORDERS) của EDIFACT cơ sở
A.1.3. Mô tả đoạn
Đoạn: | UNH | Số hiệu đoạn Trạng thái | 1 M | Mức Số lần lặp lại | 0 1 | Tiêu đề thông điệp |
Tên: Tiêu đề thông điệp
Mô tả đoạn:
EDIFACT | Trình ứng dụng | ||||
Thẻ | Tên | T.T Dạng thức | tt | Ví dụ | Sử dụng/ Giải thích |
0062 | Số hiệu tham chiếu thông điệp | M an..14 | M | +1 | Số duy nhất của thông điệp được chỉ định bởi người gửi. |
S009 | ĐỊNH DANH THÔNG ĐIỆP | M | M |
|
|
0065 | Định danh kiểu thông điệp | M an..6 | M |
| ORDERS = Thông điệp đơn đặt hàng |
0052 | Số hiệu phiên bản kiểu thông điệp | M an..3 | M | :D | D = Danh mục nháp |
0054 | Số hiệu phát hành kiểu thông điệp | M an..3 | M | :93A | 93A = Phiên bản danh mục EDIFACT 93A |
0051 | Cơ quan kiểm soát | M an..2 | M | :UN' | UN = UN/ECE/TRADE/WP.4, Thông điệp tiêu chuẩn Liên hợp quốc (UNSM) |
Giải thích:
Đây là đoạn tiêu đề thông điệp.
Ví dụ:
UNH+1+ORDERS : D : 93A : UN'
Đoạn: | BGM | Số hiệu đoạn Trạng thái | 2 M | Mức Số lần lặp lại | 0 1 | Bắt đầu thông điệp |
Tên: Số hiệu và kiểu tài liệu
Mô tả đoạn:
EDIFACT | Trình ứng dụng | ||||
Thẻ | Tên | T.T Dạng thức | tt | Ví dụ | Sử dụng/ Giải thích |
C002 | TÊN THÔNG ĐIỆP/ TÀI LIỆU | C | R |
|
|
1001 | Tên thông điệp/tài liệu, mã hóa | C an..3 | R | +220 | 220 = Order |
1004 | Số thông điệp/tàI liệu | C an..35 | R | +1-96' | Dạng thức an..8 Số tài liệu, được chỉ định bởi người gửi Số thứ tự |
Giải thích:
Ví dụ:
BGM + 220 + 1 - 96'
Đoạn: | DTM | Số hiệu đoạn Trạng thái | 3 M | Mức Số lần lặp lại | 1 1 | Ngày tháng/giờ/quá trình |
Tên: Ngày tháng thanh toán
Mô tả đoạn:
EDIFACT | Trình ứng dụng | ||||
Thẻ | Tên | T.T Dạng thức | tt | Ví dụ | Sử dụng/ Giải thích |
C507 | Ngày tháng/ giờ/ quá trình | M | M |
|
|
2005 | Hạn định ngày tháng/giờ/quá trình | M an..3 | M | +4 | 4 = Ngày tháng/giờ thanh toán |
2380 | Ngày tháng/giờ/quá trình | C an..35 | R | :19960101 | D.thức n8 Ngày tháng thanh toán |
2379 | Hạn dạng thức ngày tháng/giờ/quá trình | C an..3 | R | :102' | 102 = JJJJMMTT |
Giải thích:
Ví dụ:
DTM+4 : 19960101 : 102'
Đoạn: | DTM | Số hiệu đoạn Trạng thái | 4 M | Mức Số lần lặp lại | 1 1 | Ngày tháng/giờ/quá trình |
Tên: Ngày tháng truyền phát
Mô tả đoạn:
EDIFACT | Trình ứng dụng | ||||
Thẻ | Tên | T.T Dạng thức | tt | Ví dụ | Sử dụng/ Giải thích |
C507 | Ngày tháng/giờ/quá trình | M | M |
|
|
2005 | Hạn định ngày tháng/giờ/quá trình | M an..3 | M | +2 | 2 = Ngày tháng/giờ truyền phát, yêu cầu |
2380 | Ngày tháng/giờ/quá trình | C an..35 | R | :19960110 | D.thức n8 Ngày tháng truyền phát |
2379 | Hạn dạng thức ngày tháng/giờ/quá trình | C an..3 | R | :102' | 102 = CCYYMMDD |
Giải thích:
Đoạn này được sử dụng cho việc truyền ngày tháng truyền phát yêu cầu.
Ví dụ:
DTM+4 : 19960110 : 102'
Nhóm: | SG2 | Trạng thái | R | Số lần lặp lại | 1 | Người mua |
Trường hợp SG2 này, thông tin liên quan người mua được truyền.
Đoạn: | NAD | Số hiệu đoạn Trạng thái | 5 M | Mức Số lần lặp lại | 1 1 | Tên và địa chỉ |
Tên: Định danh người mua
Mô tả đoạn:
EDIFACT | Trình áp dụng | ||||
Thẻ | Tên | T.T Dạng thức | tt | Ví dụ | Sử dụng/ Giải thích |
3035 | Hạn định bên tham gia | M an..3 | M | +BY | BY = Người mua |
C082 | CHI TIẾT ĐỊNH DANH BÊN THAM GIA | C |
|
|
|
3039 | Định danh id bên tham gia | M an..17 | N |
|
|
C058 | TÊN VÀ ĐỊA CHỈ | C | N |
|
|
3124 | Dòng tên và địa chỉ | M an..35 | N |
|
|
C080 | TÊN BÊN THAM GIA | C | N |
|
|
3036 | Tên bên tham gia | M an..35 | R | +BONBON | Dạng thức an..10 |
C059 | ĐƯỜNG PHỐ | C | O |
|
|
3042 | Đường phố và số/P.O. Box | M an..35 | M | +SIRUPST RASSE 15 | Đường phố của người mua |
3164 | Tên thành phố | C an..35 | O |
| Thành phố của người mua |
3229 | Định danh vùng phụ trong quốc gia | C an..9 | N |
|
|
3251 | Định danh mã bưu điện | C an..9 | O | +55555' | Dạng thức n5 |
Giải thích:
Ví dụ:
NAD + BY +++ BONBON AG + SIRUPSTRASSE 15 + ZUCKERSTADT ++ 55555'
Nhóm: | SG2 | Trạng thái | R | Số lần lặp lại | 1 | Người mua |
Trường hợp SG2 này, thông tin liên quan người mua được truyền.
Đoạn: | FII | Số hiệu đoạn Trạng thái | 6 M | Mức Số lần lặp lại | 2 1 | Thông tin tổ chức tài chính |
Tên: Thông tin tài khoản ngân hàng người mua
Mô tả đoạn:
EDIFACT | Trình ứng dụng | ||||
Thẻ | Tên | T.T Dạng thức | tt | Ví dụ | Sử dụng/ Giải thích |
3035 | Hạn định bên | M an..3 | M | +BB | BB = Ngân hàng người mua |
C078 | ĐỊNH DANH TÀI KHOẢN | C | R |
|
|
3194 | Số người giữ tài khoản | C an..17 | R | +12365478 90 | D.thức n10 Số tài khoản người mua Số tài khoản người mua. Theo luật Đức cấm tài khoản giấu tên. |
3192 | Tên người giữ tài khoản | C an..35 | R | :BONBON AG | D.thức an..10 Người giữ tài khoản. Để bảo vệ vấn đề hợp pháp bất kỳ phải truyền tên người dữ tài khoản. |
C088 | ĐỊNH DANH CƠ QUAN | C | R |
|
|
3433 | Định danh tên cơ quan | C an..11 | R | +10090045 | D.thức n8 Người mua BIC |
1131 | Hạn định danh sách mã | C an..3 | R | :25 | 25 = Định danh ngân hàng |
3055 | Cơ quan chịu trách nhiệm danh sách mã, mã hóa | C an..3 | R | :131 | 131 = Hội chủ ngân hàng Đức |
3434 | Số tổ chức chi nhánh | C an..17 | O | :262 | Đây là phần tử có thể sử dụng cho đặc tả số tổ chức tài chính chi nhánh. |
1131 | Hạn định danh sách mã | C an..3 | N |
|
|
3055 | Cơ quan chịu trách nhiệm danh sách mã, mã hóa | C an..3 | N |
|
|
3432 | Tên tổ chức | C an..70 | O | :SBANK' | Tên ngân hàng người mua Chứa tên ngân hàng người mua. |
Giải thích:
Đoạn này được sử dụng cho truyền số tài khoản và ngân hàng người mua.
Ví dụ:
FII + BB + 1236547890 : BONBON AG + 10090045 : 25 : 131 : 262 ::: SBANK'
Nhóm: | SG2 | Trạng thái | R | Số lần lặp lại | 1 | Người mua |
Trường hợp SG2 này, thông tin liên quan người mua được truyền.
Nhóm: | SG3 | Trạng thái | O | Số lần lặp lại | 1 | Số VAT người mua |
Đoạn: | RFF | Số hiệu đoạn Trạng thái | 7 M | Mức Số lần lặp lại | 2 1 | Tham chiếu |
Tên: Số VAT
Mô tả đoạn:
EDIFACT | Trình ứng dụng | ||||
Thẻ | Tên | St D.thức | St | Ví dụ | Sử dụng/ Giải thích |
C506 | THAM CHIẾU | M | M |
|
|
1153 | Hạn định tham chiếu | M an..3 | M | +VA | VA = Số đăng ký VAT |
1154 | Số hiệu tham chiếu | C an..35 | R | : DE998887 7' | Số ID VAT người mua |
Giải thích:
Ví dụ:
RFF + VA : DE9988877'
Nhóm: | SG2 | Trạng thái | R | Số lần lặp lại | 1 | Người mua |
Trường hợp SG2 này, thông tin liên quan người mua được truyền.
Nhóm: | SG5 | Trạng thái | O | Số lần lặp lại | 1 | Thông tin liên hệ người mua |
Đoạn: | CTA | Số hiệu đoạn Trạng thái | 8 M | Mức Số lần lặp lại | 2 1 | Thông tin liên hệ |
Tên: Người chịu trách nhiệm cho người mua
Mô tả đoạn:
EDIFACT | Trình ứng dụng | ||||
Thẻ | Tên | St D.thức | St | Ví dụ | Sử dụng/ Giải thích |
3139 | Chức năng liên hệ, mã hóa | C an..3 | R | +IC | IC = Thông tin liên hệ |
C056 | CHI TIẾT CÁ NHÂN HOẶC VĂN PHÒNG | C |
|
|
|
3413 | Định danh cá nhân hoặc văn phòng | C an..17 | O O | +Bart Simpson' | D.thức an..15 Liên hệ người mua |
Giải thích:
Ví dụ:
CTA + IC + Bart Simpson'
Nhóm: | SG2 | Trạng thái | R | Số lần lặp lại | 1 | Người mua |
Trường hợp SG2 này, thông tin liên quan người mua được truyền.
Nhóm: | SG5 | Trạng thái | O | Số lần lặp lại | 1 | Thông tin liên hệ người mua |
Đoạn: | COM | Số hiệu đoạn Trạng thái | 9 M | Mức Số lần lặp lại | 3 1 | Liên hệ truyền thông |
Tên: Số điện thoại
Mô tả đoạn:2
EDIFACT | Trình áp dụng | ||||
Thẻ | Tên | St D.thức | St | Ví dụ | Sử dụng/ Giải thích |
C076 | Liên hệ truyền thông | M | M |
|
|
3148 | Số truyền thông | M an..25 | M | +05368- 22347 | D.thức an..12 Số điện thoại người mua |
3155 | Hạn định kênh truyền thông | M an..3 | M | :TE' | TE = Điện thoại |
Giải thích:
Ví dụ:
COM + 05368 - 22347 : TE'
Nhóm: | SG2 | Trạng thái | R | Số lần lặp lại | 1 | Người mua |
Trường hợp SG2 này, thông tin liên quan người mua được truyền.
Nhóm: | SG5 | Trạng thái | O | Số lần lặp lại | 1 | Thông tin liên hệ người mua |
Đoạn: | COM | Số hiệu đoạn Trạng thái | 10 M | Mức Số lần lặp lại | 3 1 | Liên hệ truyền thông |
Tên: Liên hệ truyền thông
Mô tả đoạn:
EDIFACT | Trình ứng dụng | ||||
Thẻ | Tên | St D.thức | St | Ví dụ | Sử dụng/ Giải thích |
C076 | Liên hệ truyền thông | M | M |
|
|
3148 | Số truyền thông | M an..25 | M | +05368- 22555 | D.thức an..12 Số fax người mua |
3155 | Hạn định kênh truyền thông | M an..3 | M | :FX' | FX = Fax |
Giải thích:
Ví dụ:
COM + 05368 - 22555 : FX'
Nhóm: | SG2 | Trạng thái | R | Số lần lặp lại | 1 | Người mua |
Trường hợp SG2 này, thông tin liên quan người mua được truyền.
Đoạn: | NAD | Số hiệu đoạn Trạng thái | 11 M | Mức Số lần lặp lại | 1 1 | Tên và địa chỉ |
Tên: Định danh người bán
Mô tả đoạn:
EDIFACT | Trình ứng dụng | ||||
Thẻ | Tên | St D.thức | St | Ví dụ | Sử dụng/ Giải thích |
3035 | Hạn định bên | M an..3 | M | +SE | SE = Người bán |
C082 | CHI TIẾT ĐỊNH DANH BÊN | C | N |
|
|
3039 | Định danh id bên | M an..17 | N |
|
|
C058 | TÊN VÀ ĐỊA CHỈ | C | N |
|
|
3124 | Dòng tên và địa chỉ | M an..35 | N |
|
|
C080 | TÊN BÊN | C | R |
|
|
- 3036 | Tên bên | M an..35 | M | +KAKAO GMBH | D.thức an..10 Tên người bán |
C059 | PHỐ | C | O |
|
|
3042 | Số và phố/P.O. Box | M an..35 | M | +FRUCHT STRASSE 1 | Phố người bán |
3164 | Tên thành phố | C an..35 | O | +SAHNEB ERG | Thành phố người bán |
3229 | Định danh vùng phụ trong quốc gia | C an..9 | N |
|
|
3251 | Định danh mã bưu điện | C an..9 | O | +98765' | D.thức n5 Mã bưu điện người bán |
Giải thích:
Ví dụ:
NAD + SE +++ KAKAO GMBH + FRUCHTSTRASSE 1 + SAHNEBERG ++ 98765'
Nhóm: | SG7 | Trạng thái | O | Số lần lặp lại | 1 | Tiền tệ |
Đoạn: | CUX | Số hiệu đoạn Trạng thái | 12 M | Mức Số lần lặp lại | 1 1 | Tiền tệ |
Tên: Tiền tệ thanh toán
Mô tả đoạn:
EDIFACT | Trình ứng dụng | ||||
Thẻ | Tên | St D.thức | St | Ví dụ | Sử dụng/ Giải thích |
C504 | CHI TIẾT TIỀN TỆ | C | R |
|
|
6347 | Hạn định chi tiết tiền tệ | M an..3 | M | +2 | 2 = Tiền tệ tham chiếu |
6345 | Tiền tệ, mã hóa | C an..3 | R | :EUR | Tiền tệ thanh toán |
6343 | Hạn định tiền tệ | C an..3 | O | :9' | 9 = Tiền tệ thanh toán |
Giải thích:
Ví dụ:
CUX + 2 : EUR : 9'
Nhóm: | SG25 | Trạng thái | R | Số lần lặp lại | 10 | Dòng hạng mục |
Đoạn: | LIN | Số hiệu đoạn Trạng thái | 13 M | Mức Số lần lặp lại | 1 1 | Dòng hạng mục |
Tên: Số mặt hàng của người cung cấp
Mô tả đoạn:
EDIFACT | Trình ứng dụng | ||||
Thẻ | Tên | St D.thức | St | Ví dụ | Sử dụng/ Giải thích |
1082 | Số dòng hạng mục | C n..6 | O | +1 | D.thức n..5 Số dòng |
1229 | Yêu cầu hành động/thông báo, mã hóa | C an..3 | N |
|
|
C212 | ĐỊNH DANH SỐ HẠNG MỤC | C | R |
|
|
7140 | Số hạng mục | C an..35 | R | +2001 | D.thức an..10 Số hạng mục |
7143 | Kiểu số hạng mục, mã hóa | C an..3 | R | :SA' | SA = Số mặt hàng của người cung cấp |
Giải thích:
Phần dòng hạng mục một đợt thanh toán bao gồm một hoặc nhiều lần lặp lại của một nhóm đoạn, bắt đầu với một đoạn LIN. Mỗi đoạn LIN nói tới một sản phẩm chính xác.
Ví dụ:
LIN + 1 ++ 2001 : SA'
Nhóm: | SG25 | Trạng thái | R | Số lần lặp lại | 10 | Dòng hạng mục |
Đoạn: | IMD | Số hiệu đoạn Trạng thái | 14 O | Mức Số lần lặp lại | 2 1 | Mô tả hạng mục |
Tên: Mô tả ngắn sản phẩm
Mô tả đoạn:
EDIFACT | Trình ứng dụng | ||||
Thẻ | Tên | St D.thức | St | Ví dụ | Sử dụng / Giải thích |
7077 | Kiểu mô tả hạng mục, mã hóa | C an..3 | R | +F | F = Mẫu tự do |
7081 | Đặc điểm hạng mục, mã hóa | C an..3 | N |
|
|
C273 | MÔ TẢ HẠNG MỤC | C | R |
|
|
7009 | Định danh mô tả hạng mục | C an..7 | N |
|
|
1131 | Hạn định danh sách mã | C an..3 | N |
|
|
3055 | Cơ quan chịu trách nhiệm danh sách mã, mã hóa | C an..3 | N |
|
|
7008 | Mô tả hạng mục | C an..35 | R |
| D.thức an..20 Mô tả hạng mục, dòng 1, nếu đoạn này được sử dụng, sự mô tả phải được truyền. Dòng văn bản hạng mục 1 |
7008 | Mô tả hạng mục | C an..35 | O | :BRAUN' | D.thức an..20 Dòng văn bản hạng mục 2 |
Giải thích: Ví dụ:
IMD + F ++ ::: SCHOKOLADENMASSE : BRAUN'
Nhóm: | SG25 | Trạng thái | R | Số lần lặp lại | 10 | Dòng hạng mục |
Đoạn: | QTY | Số hiệu đoạn Trạng thái | 15 O | Mức Số lần lặp lại | 2 1 | Số lượng |
Tên: Số lượng thanh toán
Mô tả đoạn:
EDIFACT | Trình ứng dụng | ||||
Thẻ | Tên | St D.thức | St | Ví dụ | Sử dụng / Giải thích |
C186 | Chi tiết số lượng | M | M |
|
|
6063 | Hạn định số lượng | M an..3 | M | +21 | 21 = Số lượng thanh toán |
6060 | Số lượng | M n..15 | M | :2 | D.thức n..5 Số lượng thanh toán |
6411 | Hạn định đơn vị đo lường | C an..3 | O | :TNE' | Đơn vị đo lường TNE = Tấn (1000 kg) * KGM = Kilogram * GRM = Gram * LBR = Pound GB, US (0,45359237 kg) LTR = Litre (1 dm3) * DZN = Dozen |
Giải thích:
Ví dụ:
QTY + 21 : 2 : TNE'
Nhóm: | SG25 | Trạng thái | R | Số lần lặp lại | 10 | Dòng hạng mục |
Đoạn: | MOA | Số hiệu đoạn Trạng thái | 16 O | Mức Số lần lặp lại | 2 1 | Tổng tiền |
Tên: Tổng dòng hạng mục
Mô tả đoạn:
EDIFACT | Trình ứng dụng | ||||
Thẻ | Tên | St D.thức | St | Ví dụ | Sử dụng/ Giải thích |
C516 | TỔNG TIỀN | M | M |
|
|
5025 | Hạn định kiểu tổng tiền | M an..3 | M | +203 | 203 = Tổng dòng hạng mục |
5004 | Tổng tiền | C n..18 | R | :2800' | Tổng dòng hạng mục |
Giải thích:
Đoạn này bao gồm tổng giá trị dòng hạng mục (giá nhân số lượng).
Ví dụ:
MOA + 203 : 2800'
Nhóm: | SG25 | Trạng thái | R | Số lần lặp lại | 10 | Dòng hạng mục |
Trường hợp SG2 này, thông tin liên quan người mua được truyền.
Nhóm: | SG27 | Trạng thái | O | Số lần lặp lại | 10 | Giá hạng mục |
Đoạn: | PRI | Số hiệu đoạn Trạng thái | 17 M | Mức Số lần lặp lại | 2 1 | Chi tiết giá |
Tên: Giá mỗi hạng mục / đơn vị
Mô tả đoạn:
EDIFACT | Trình ứng dụng | ||||
Thẻ | Tên | St D.thức | St | Ví dụ | Sử dụng/ Giải thích |
C509 | THÔNG TIN GIÁ | C | R |
|
|
5125 | Hạn định giá | M an..3 | M | +AAB | AAB = Tổng tính |
5118 | Giá | C n..15 | R | :1400 | D.thức n..12 Giá đơn vị |
5375 | Kiểu giá, mã hóa | C an..3 | N |
|
|
5387 | Hạn định kiểu giá | C an..3 | O | :CAT | CAT = Tuyển tập giá |
5284 | Giá đơn vị cơ bản | C n..9 | N |
|
|
6411 | Hạn định đơn vị đo lường | C an..3 | O | :TNE' | PCE = Vật mẫu KGM = Kilogram LTR = Litre (1 dm3) TNE = Tấn (1000 kg) |
Giải thích:
Ví dụ:
PRI + AAB : 1400 :: CAT :: TNE'
Đoạn: | UNS | Số hiệu đoạn Trạng thái | 18 M | Mức Số lần lặp lại | 0 1 | Điều khiển vùng |
Tên: Điều khiển vùng
Mô tả đoạn:
EDIFACT | Trình ứng dụng | ||||
Thẻ | Tên | St D.thức | St | Ví dụ | Sử dụng/ Giải thích |
0081 | Định danh vùng | M a1 | M | +S' | S = Sự chia vùng khái quát hóa/chi tiết |
Giải thích:
Ví dụ:
UNS + S'
Đoạn: | MOA | Số hiệu đoạn Trạng thái | 19 R | Mức Số lần lặp lại | 0 1 | Tổng tiền |
Tên: Tổng giá trị
Mô tả đoạn:
EDIFACT | Trình ứng dụng | ||||
Thẻ | Tên | St D.thức | St | Ví dụ | Sử dụng/ Giải thích |
C516 | TỔNG TIỀN | M | M |
|
|
5025 | Hạn định kiểu tổng tiền | M an..3 | M | +86 | 86 = Thông điệp tổng giá trị tiền |
5004 | Tổng tiền | C n..18 | R | :2800' | D.thức n..12 Giá trị thanh toán tổng |
Giải thích:
Ví dụ:
MOA + 86 : 2800'
Đoạn: | UNT | Số hiệu đoạn Trạng thái | 20 M | Mức Số lần lặp lại | 0 1 | Đuôi thông điệp |
Tên: Đuôi thông điệp
Mô tả đoạn:
EDIFACT | Trình ứng dụng | ||||
Thẻ | Tên | St D.thức | St | Ví dụ | Sử dụng/ Giải thích |
0074 | Số đoạn trong một thông điệp | M n..6 | M | +20 |
|
0062 | Số tham chiếu thông điệp | M an..14 | M | +1' | Số duy nhất của thông điệp được chỉ định bởi người gửi: phải bằng giá trị của DE 0062 trong UNH. |
Giải thích:
Ví dụ:
UNT + 20 + 1'
A.2. Cấu trúc XML tạo ra
A.2.1. Lược đồ XML với thẻ EDI và tên miền
CHÚ THÍCH: Tên miền ‘din’ trong ví dụ phần này chỉ có mục đích minh hoạ và cũng có thể sử dụng tên miền phù hợp bất kỳ khác.
Ví dụ thông điệp XML cho lược đồ trên:
A.2.2 Lược đồ XML khác với thẻ “nói”
Ví dụ thông điệp XML cho lược đồ trên:
TÀI LIỆU THAM KHẢO
ISO 8879, Ind.thứcion processing - Text and office systems - Standard Generalized Markup Language
(SGML). (Xử lý thông tin - Hệ thống văn phòng và văn bản - Ngôn ngữ đánh dấu khái quát hóa tiêu chuẩn (SGML)).
TCVN ISO/TS 16668, Basic Semantics Register (BSR). (Bộ đăng ký ngữ nghĩa cơ sở (BSR)).
XML Schema - Part 1 : Structures, http://www.w3.org/TR/2001/REC-xmlschema-1-20010502. (Lược đồ XML - Phần 1 : Cấu trúc, http://www.w3.org/TR/2001/REC-xmlschema-1-20010502).
XML Schema - Part 2 : Datatypes, http://www.w3.org/TR/2001/REC-xmlschema-2-20010502. (Lược đồ XML - Phần 2 : Kiểu dữ liệu, http://www.w3.org/TR/2001/REC-xmlschema-2-20010502).
MỤC LỤC
Lời nói đầu
Lời giới thiệu
1. Phạm vi áp dụng
2. Tài liệu viện dẫn
3. Thuật ngữ, ký hiệu và chữ viết tắt
3.1. BSR
3.2. BSU
3.3. DTD
3.4. EDI
3.5. EDIFACT
3.6. ELEMENT (phần tử)
3.7. HTML
3.8. MIG
3.9. NAME (tên)
3.10. SGML
3.11. Tag
3.12. Template
3.13. XLL
3.14. XML
3.15. XSD
3.16. XSL
3.17. W3C
4. Nội dung tiêu biểu của hướng dẫn thực thi thông điệp
4.1. Mức: MIG
4.2. Mức: Kiểu thông điệp
4.3. Mức: Đoạn và phần tử dữ liệu hỗn hợp
5. Các yêu cầu của các quy tắc tạo lược đồ
6. Quy tắc tạo lược đồ XML từ các MIG EDI
6.1. Quy tắc 1: (đặt tên thẻ)
6.1.1. Biến thể 1
6.1.2. Biến thể 2
6.2. Quy tắc 2: Cấu trúc
6.2.1.
6.2.2.
6.2.3.
6.3.4.
6.3. Quy tắc 3: Cấu trúc tối ưu
6.3.1.
6.3.2.
6.3.3.
6.4. Quy tắc 4: Trạng thái
6.5. Quy tắc 5: Số lần xuất hiện lớn nhất
6.6. Quy tắc 6: Dạng thức thức phần tử dữ liệu
6.6.1.
6.6.2.
6.7. Quy tắc 7: Danh sách mã và mã do người sử dụng định nghĩa
6.7.1.
6.7.2.
6.7.3.
6.7.4.
6.7.5.
6.8. Quy tắc 8: Tên của đối tượng EDI
6.9. Quy tắc 9: Chi tiết ánh xạ
6.10. Quy tắc 10: Tập của bộ lưu trữ dữ liệu cùng tên
6.10.1. Cấu trúc
6.10.2. Trạng thái
6.10.3. Dạng thức
6.10.4. Danh sách mã
Phụ lục A
A.1. Cấu trúc EDIFACT cơ bản cho ánh xạ
A.1.1. Khái quát
A.1.3. Mô tả đoạn
A.2. Cấu trúc XML tạo ra
A.2.1. Lược đồ XML với thẻ EDI và tên miền
A.2.2. Lược đồ XML khác với thẻ “nói”
Click Tải về để xem toàn văn Tiêu chuẩn Việt Nam nói trên.