This post is in continuation with EDI Process components part one .
Transaction : A transaction is the electronic equivalent of a business document. A transaction is usually divided into three areas: header area, detail area, and summary area. The header area consists of segments that apply to the entire document, and is usually mandatory.
For example, in a purchase order, vendor number and vendor address are part of the header segments. The detail area contains document details. The items being ordered and their quantities are considered detail segments. The summary area consists of data that summarizes the entire document, and the total amount and taxes are part of the summary segments.
Segment : A segment is equivalent to a record in a document. A data segment has the following attributes: a unique ID, a name, a flag indicating whether it is optional or mandatory, and a number of occurrences. A group of segments can be combined to form a loop, which can also be mandatory or optional, and can be nested as well.
Segments are contained in a segment directory .
A segment consists of a sequence of logically related data elements. Data elements are separated by a data element separator and can be mandatory or optional. Some data elements are conditional, or mandatory, in certain situations.
Data Elements : Data elements are the smallest unit of information in a transaction and are defined in the data element dictionary (X12.3). A data element is identified by a data element reference number, a data type, and a minimum and maximum length.
UN/EDIFACT (United Nations EDI for Administration, Commerce, and Transport) was formed in 1985, using the ANSIX12 and UNTDI (United Nations Trade Data Interchange) as the base standards. The purpose of the standard was to develop an international standard to meet the needs of a global economy.
Most companies are moving toward adopting EDIFACT because of its international recognition. EDIFACT is quite similar to ANSI X12, with some minor differences in terminology and layout.
EDIFACT calls business documents messages and represents them by a name such as ORDERS for a purchase order, whereas ANSI X12 calls them transactions and represents them by a number such as 850 for a purchase order.
EDIFACT uses different terminology for fields. Conditional fields of EDIFACT are the same as optional fields in ANSI X12.
EDIFACT uses the same segment in multiple places, whereas ANSI has a specific use for each segment.
EDIFACT has additional segments that apply to international trade.
Application Programs
Application programs are responsible for generating and processing data in business documents. These application programs are part of the application suite commonly referred to as ERP (Enterprise Resource Planning). ERP systems meet a broad range of a company's business needsSAP R/3 is an example. Most ERP vendors recognize the business needs for EDI and thus enable their software to support EDI processes. An ERP system must do the following:
Support standard EDI transactions in the business area of interest. For example, if the focus of a company is shipping and distribution, the software must support basic shipping transactions.
Related Posts :
EDI Process components
Business Processing using EDI
Introduction to EDI
EDI with message control scenario with purchase order and part two
Transaction : A transaction is the electronic equivalent of a business document. A transaction is usually divided into three areas: header area, detail area, and summary area. The header area consists of segments that apply to the entire document, and is usually mandatory.
For example, in a purchase order, vendor number and vendor address are part of the header segments. The detail area contains document details. The items being ordered and their quantities are considered detail segments. The summary area consists of data that summarizes the entire document, and the total amount and taxes are part of the summary segments.
Segment : A segment is equivalent to a record in a document. A data segment has the following attributes: a unique ID, a name, a flag indicating whether it is optional or mandatory, and a number of occurrences. A group of segments can be combined to form a loop, which can also be mandatory or optional, and can be nested as well.
Segments are contained in a segment directory .
A segment consists of a sequence of logically related data elements. Data elements are separated by a data element separator and can be mandatory or optional. Some data elements are conditional, or mandatory, in certain situations.
Data Elements : Data elements are the smallest unit of information in a transaction and are defined in the data element dictionary (X12.3). A data element is identified by a data element reference number, a data type, and a minimum and maximum length.
UN/EDIFACT (United Nations EDI for Administration, Commerce, and Transport) was formed in 1985, using the ANSIX12 and UNTDI (United Nations Trade Data Interchange) as the base standards. The purpose of the standard was to develop an international standard to meet the needs of a global economy.
Most companies are moving toward adopting EDIFACT because of its international recognition. EDIFACT is quite similar to ANSI X12, with some minor differences in terminology and layout.
EDIFACT calls business documents messages and represents them by a name such as ORDERS for a purchase order, whereas ANSI X12 calls them transactions and represents them by a number such as 850 for a purchase order.
EDIFACT uses different terminology for fields. Conditional fields of EDIFACT are the same as optional fields in ANSI X12.
EDIFACT uses the same segment in multiple places, whereas ANSI has a specific use for each segment.
EDIFACT has additional segments that apply to international trade.
Application Programs
Application programs are responsible for generating and processing data in business documents. These application programs are part of the application suite commonly referred to as ERP (Enterprise Resource Planning). ERP systems meet a broad range of a company's business needsSAP R/3 is an example. Most ERP vendors recognize the business needs for EDI and thus enable their software to support EDI processes. An ERP system must do the following:
Support standard EDI transactions in the business area of interest. For example, if the focus of a company is shipping and distribution, the software must support basic shipping transactions.
- Make the data necessary for EDI messages readily available.
- Document the EDI processes and functionality.
- Be flexible enough to incorporate business requirements within the existing process.
- Provide support for enhancing existing transactions.
- Contain easily configurable and manageable systems.
- Contain a sufficient number of control points to meet business needs.
- Exhibit a disciplined approach for controlling the flow of documents within the organization, from error handling to the approval process.
- Be integrated with EDI translation software vendors.
- Provide system limits and performance measures if a company expects a large volume of EDI.
- transactions.(22)
Related Posts :
EDI Process components
Business Processing using EDI
Introduction to EDI
EDI with message control scenario with purchase order and part two
No comments :
Post a Comment