This chapter contains the following topics:
An interface table (also called a Z table) is a working table where non-JD Edwards EnterpriseOne information can be stored and then processed into JD Edwards EnterpriseOne. You can also use interface tables to retrieve JD Edwards EnterpriseOne data. JD Edwards EnterpriseOne interface tables mirror JD Edwards EnterpriseOne application tables.
JD Edwards EnterpriseOne provides predefined interface tables for some applications. You can also create your own interface tables as long as your interface table is formatted in accordance with JD Edwards EnterpriseOne standards.
If you receive an error message when the interface table is processed, you can use a revision application to make corrections to the data and then reprocess the data in batch or transaction mode. After you have successfully processed the data in the interface table, you should run a purge application to remove all records from the interface table and to any remove secondary interface tables from the system.
Note:
You usually use a batch interface to collect transactions over a period of time and then process all of the transactions at once.Each JD Edwards EnterpriseOne transaction uses a set of interface tables. Some files share a common set of interface tables. The interface table name is based on the JD Edwards EnterpriseOne application table name and has Z1 as a suffix. For example, if the application table is the F4211 table, the interface table is the F4211Z1 table.
Use the these guidelines to determine the based-on table:
Inbound is based on the application table that is updated with data from the interface table.
Outbound is based on the application table that has data extracted from it and placed in the interface table.
Both the inbound and outbound directions of an internal transaction within a system use a single set of interface tables. For example, for a sales order in the Sales Order system, the inbound customer order (850) and the outbound order acknowledgment (855) share a set of interface tables.
If the interface table is used for both inbound and outbound transactions, the based-on table should be the same application table. In the Sales Order example with an inbound customer order and an outbound order acknowledgment, the detail interface table is based on the F4211 table.
If the interface table exceeds 250 columns or has a record length greater than 1968, an additional interface table is needed for the remaining columns. Columns in the additional interface table should contain infrequently used data. The additional interface table is named after the primary interface table with a letter, starting with A, after the Z1 suffix. For example, if the primary interface table is F4211Z1, the additional table is F4211Z1A.
The beginning of the table has these columns, which act as control fields:
User ID (EDUS) (key field)
Batch Number (EDBT) (key field)
Transaction Number (EDTN) (key field)
Line Number (EDLN) (key field)
Document Type (EDCT)
Transaction Type (TYTN)
Translation Format (EDFT)
Transmission Date (EDDT)
Direction Indicator (DRIN)
Number of Detail Lines (EDDL)
Processed (EDSP)
Trading Partner ID (PNID)
Action Code (TNAC)
You must use the key structure previously discussed.
The end of the table has the these columns, which are reserved for user and audit fields:
User Reserved Code (URCD)
User Reserved Date (URDT)
User Reserved Amount (URAT)
User Reserved Number (URAB)
User Reserved Reference (URRF)
Transaction Originator (TORG)
User ID (USER)
Program ID (PID)
Work Station ID (JOBN)
Date Updated (UPMJ)
Time of Day (TDAY)
The middle of the table has all of the columns from the based-on application table, excluding user reserved and audit field columns. An exception to this is when the interface table is near the 250-column limit or the 1968-record length limit. In this case, columns from the application table that most likely will not be needed should be excluded.
Prefixes for the table columns are SY for the header and SZ for the detail.
Change or match interface tables, such as a cash receipt or purchase receipt, might require additional columns that correspond to user input capable controls on an interactive form.
A header table is not required for every transaction.
Note:
If you create custom interface tables, use the structure and format described in this chapter.You use interface tables to import non-JD Edwards EnterpriseOne transactions into the live JD Edwards EnterpriseOne database. These non-JD Edwards EnterpriseOne transactions are referred to as Z transactions. Inbound interface tables are based on the JD Edwards EnterpriseOne application table where the transaction is stored. Once records are correctly updated to the appropriate interface table, you can update the record to the JD Edwards EnterpriseOne database.
See Also:
You can use interface tables to retrieve information from JD Edwards EnterpriseOne. Outbound interface tables are based on the JD Edwards EnterpriseOne application table from where the data is extracted. You can retrieve records from JD Edwards EnterpriseOne by running an extraction batch process, by using a subsystem business function, or by generating a Z event.
You copy the records from the JD Edwards EnterpriseOne application tables to the JD Edwards EnterpriseOne outbound interface tables using the extraction batch process that is specifically set up for the type of document you are sending.
You initiate the extraction batch process for applications that support extraction batch processing. The extraction batch process displays a version list of report features. You can run an existing version, change an existing version, or add a version. You can also change the processing options and data selection options for that version to fit your needs.
When you run the extraction batch process, the program retrieves data from the JD Edwards EnterpriseOne application tables for the transaction and copies the data into the outbound interface tables. The system also generates an audit report that lists the records that completed successfully. Errors are placed on the audit report and also sent to the employee work center. You can use a revisions application to correct errors in the interface table records.
You can use the generic outbound subsystem business function, Add Transaction To Subsystem Queue (B0000176), to write a record to the subsystem data queue to specify a batch process that needs to be awakened in the subsystem. This business function starts processing of a batch of one (single transaction). The business function also passes keys to the subsystem data queue.
The data structure for the outbound transaction is:
Line Number (EDLN)
Transaction Type (TYTN)
Document Type (DCTO)
Action Code (TNAC)
You use the revision application to add, delete, edit, and review transactions in the interface tables. You can use a revision application to correct the record in error. After you make a change to the interface table, you run the process again. You can continue to make corrections and rerun the transaction process until the program completes without errors. The name is based on the detail interface table. For example, if the tables for Sales Order Entry are F4201Z1 and F4211Z1, the revision application is P4211Z1. The revisions application can call the appropriate purge named event rule to delete records from the interface table.
You should run a purge batch process periodically after you have successfully processed the data in the interface tables. The purge batch process should have one or two sections; the number of sections depends on the interface tables. The purge batch process calls the purge named event rule (NER). The name of the purge batch process is based on the revisions application with a P suffix. For example, if the revisions application is P4211Z1, the purge batch process is R4211Z1P.
Purge NERs have two modes:
Header mode, which deletes the header record and all associated records in independent tables.
Detail mode, which deletes the detail record and all associated records in dependent tables.
The purge NER is named after the purge batch process. Only eight characters are allowed for the NER name. If the name has nine characters using these standards, remove the P suffix. For example, if the purge batch process is R4211Z1P, the purge NER is N4211Z1P.
When a before image for net change is deleted, the corresponding after image is also deleted. When an after image is deleted, the corresponding before image is also deleted.
The JD Edwards EnterpriseOne Data Interface for Electronic Data Interchange (EDI) system acts as an interface between the JD Edwards EnterpriseOne system data and the translator software. In addition to exchanging EDI data, this data interface can also be used for general interoperability and electronic commerce needs where a file-based interface meets the business requirements.
See Also:
JD Edwards EnterpriseOne Data Interface for Electronic Data Interchange 9.0 Implementation Guide.
Table conversion is a special form of Universal Batch Engine (UBE) that enables you to do high-speed manipulation of data in tables. JD Edwards EnterpriseOne has a table conversion utility that you can use to gather, format, export, and import enterprise data. The table conversion tool enables you to transfer and copy data and to delete records from tables.
If you have set up an Output Stream Access (OSA) interface, you can pass JD Edwards EnterpriseOne data to another software program for processing and formatting. OSA can use its own set of commands or it can use an XML library.
The JD Edwards EnterpriseOne Advanced Planning Agent (APAg) is a tool for batch extracting, transforming, and loading of data. APAg supports access to data sources in the form of relational databases, flat file format, and other data or message encoding, such as XML. APAg also moves data from one place to another and initiates tasks related to the movement of the data.
See JD Edwards Supply Chain Planning, Advanced Planning Agent Guide.