CN108959202B

CN108959202B - Device for processing non-electronic data exchange data

Info

Publication number: CN108959202B
Application number: CN201710369009.3A
Authority: CN
Inventors: M·德瑞奇卡
Original assignee: Molex LLC
Current assignee: Molex LLC
Priority date: 2017-05-23
Filing date: 2017-05-23
Publication date: 2023-02-14
Anticipated expiration: 2037-05-23
Also published as: TWI651949B; TW201902184A; CN108959202A

Abstract

The present disclosure relates to an apparatus for processing non-EDI data including integrating the non-EDI customer data into an entity's EDI system and analyzing the non-EDI customer data using the EDI system. The apparatus loads the customer profile and provides a user interface for inputting non-EDI customer data and a graph of the relationship between the non-EDI data and the EDI data in the EDI system to generate the EDI data as input to the EDI system.

Description

Device for processing non-electronic data exchange data

Technical Field

The present disclosure relates generally to data exchange between different devices, and more particularly, to a device for integrating information that is not inbound via an EDI system (electronic data exchange system) into the EDI system and/or processing the information to make it suitable for analysis/statistical analysis.

Background

EDI (electronic data interchange) is a method for providing standard electronic communication for exchanging data via any electronic means. By following the same standard, two different companies or organizations may exchange documents (such as purchase orders, bills, shipping notices, and many others) electronically, even in two different countries. There are many EDI standards (including X12EDI, EDIFACT, etc.), some of which address the needs of a particular industry or region. The standard is used to make EDI a "strictly formatted message machine-machine interaction". EDI can then formally be defined as: with the agreed message standards, no manual intervention is required to transfer structured data from one computer system to another.

Any method agreed upon by the sender and the recipient may be used to transmit the EDI. This includes a variety of technologies including modem (asynchronous and synchronous), electronic mail (e-mail), file Transfer Protocol (FTP), hypertext transfer protocol (HTTP), AS1, AS2, AS4, etc. More and more trading partners use networks for transmission, i.e., delivery of EDI files via e-mail. Trading partners may interact directly or through intermediaries such as Value Added Networks (VANs).

EDI files typically contain the same information that would normally be found in paper files for the same organizational function. For example, a manufacturer uses EDI 940 to order from a warehouse to a ship to tell a retailer the products of the warehouse to the ship. Typically having a list of "ship to" addresses, "payer" addresses, and product numbers, typically Universal Product Codes (UPCs), and quantities. Another example is the setting of messages between sellers and buyers, such as invitation to quote (RFQ), bids in response to RFQ, purchase orders, purchase order confirmation, shipping notices, receipt notices, bills, and payment notices. EDI is not, however, limited to only business data relating to commerce but encompasses all areas such as medicine (e.g., patient records and experimental results), transportation (e.g., shipping container and transportation information), engineering and construction, and the like.

Referring to fig. 1, fig. 1 illustrates an example of a conventional EDI architecture for exchanging EDI files with EDI systems between two trading companies, respectively, with a Value Added Network (VAN) therebetween. The EDI system of each company includes a communication device for receiving the EDI file, an EDI conversion device for translating and converting the EDI file into a format capable of being input to the company's own internal information system.

For "outbound" files, the EDI system will export the file (or read the database) from the company's internal information system or ERP (Enterprise resource planning) and convert the file to the appropriate format for the translator. The translator (typically translation software) will then "validate" the file to ensure that it meets the standards agreed upon by the trading partner, convert the file to "EDI" format (adding the appropriate identifiers and control structures) and send the file to the trading partner using the appropriate communication protocol, either indirectly via the VAN or directly using a protocol such AS FTP or AS 2.

For "inbound" files, the EDI system may receive the EDI file indirectly via the VAN or directly using a protocol such AS FTP or AS2, obtain the received EDI file, verify that the trading partner sending the EDI file is a valid trading partner, that the structure of the EDI file satisfies the EDI standard, and that the corresponding fields of the information transformation conform to the agreed-upon protocol. Typically, the first step is to receive the EDI file from the mailbox through the translator, which will create a fixed length or variable length file or format in XML tags. The next step is to convert/translate the document, which the translator creates into a format that can be input into the company's own internal information system or ERP. This can be accomplished using a standard data conversion language such as XSLT, using a custom program, an integrated proprietary "mapper," or an integrated standard-based graphical "mapper. The final step is to enter the converted file into the company's own internal information system.

For example, referring to the upper portion of fig. 2 and 3, for an "inbound" process, the company's translator may be a product of IBM corporation, namely a Sterling B2B integrator (abbreviated SI), which converts EDI formatted files received from an EDI mail server/file server, such as X12, TXT, XML, CSV, etc., into SAP IDOC format. Then, the company's conversion software, such as SAP AG company's product SAP system, converts the SAP IDOC format file into a format that can be input into the company's own internal information system, and finally inputs the converted file into the company's own internal information system.

One very important advantage of EDI systems is the speed at which trading partners receive information from EDI files and integrate it into their own internal systems.

However, quite a few trading partners are reluctant to switch to the EDI platform and they still send non-EDI files, resulting in slow and high chance of error for their partners to integrate the information.

By way of example, orders are common to trading partners such as suppliers and their customers. Orders include purchase orders, modified orders, forecast orders, and the like.

It is common for a customer company to have an original (Excel-based) infrastructure whose employees are accustomed to sending Excel orders to suppliers that employ the EDI system. The person responsible for the order in the supplier, such as a customer service representative (CSR for short), would have to manually read and process the information in the Excel order and enter the information into the supplier's own internal system. Manual processing implies low efficiency and high repetition rate and implies high error rates.

Furthermore, since it is very convenient to send mail using any PC or handheld device such as a cell phone, many customers send orders to the CSR in the supplier by mail, which results in slow integration of information and high error rates.

Furthermore, because the customer may change the order by mail or simply by telephone many times, the CSR in the supplier will have to manually read the information of the mail or record the content of the telephone and change it each time in the supplier's own system. Moreover, they will often have to turn to their own company's EDI/development department/IT team to change the mapping (mapping) so that they can change this information.

Regardless of whether the format of the non-EDI order is Excel, other form programs or mail, even from a telephone call only, etc., there are a wide variety of customer requirements that need to be entered into the vendor's own system, including the content/layout/format terms and conditions agreed between the customer and vendor.

In addition, the need to use various data for business analysis/statistical analysis is growing. Data/information entered into the vendor's own system via the EDI system can be readily used to perform analysis/statistical analysis, whereas data/information not via the EDI system is not.

Disclosure of Invention

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the description. This summary is not intended to identify key features or essential features of the claimed subject matter. Nor is it intended to be used to limit the scope of the claimed subject matter.

In one embodiment, a user terminal is disclosed for integrating non-EDI customer data into an entity's EDI system, the user terminal comprising: a processor; a display; and a memory for storing instructions executable by the processor. The processor is configured to perform: logging in to a server; opening a macro provided by a server; creating a local instance of the macro on the user terminal through the macro; receiving customer profile data through a macro; obtaining, by the macro, a relationship diagram between the formats of the non-EDI client data and the format of the EDI client data used by the first EDI system component of the EDI system, on a local instance of the macro on the user terminal; generating EDI client data based on the relationship graph and the non-EDI client data through the macro; the EDI client data is sent to a server, which integrates the EDI client data into a first EDI component of the EDI system.

In another embodiment, a server is disclosed for integrating non-EDI customer data into an entity's EDI system, the server comprising: a processor; and a memory for storing instructions executable by the processor. The processor is configured to perform: receiving a login request from a user terminal; opening a macro provided by a server; creating a local instance of the macro on the user terminal through the macro; receiving client archive data through the macro; loading, by the macro, customer profile data from a profile repository to the local instance of the macro on the user terminal based on a customer profile login ID; receiving EDI client data from the user terminal after the user terminal generates EDI client data based on non-EDI client data; and integrating the EDI customer data into a first EDI component of an EDI system.

In another embodiment, a user terminal is disclosed for integrating non-EDI customer data into an entity's EDI system, comprising: a processor; a display; and a memory for storing instructions executable by the processor. The processor is configured to perform: logging in to a server; opening a macro provided by the server; creating a local instance of a macro on a user terminal through the macro; loading, by the macro, client profile data from a profile repository to a local instance of the macro on the user terminal based on a client profile login ID; obtaining, by the macro, on a local instance of the macro of the user terminal, a relationship graph between the non-EDI client data and the format of the EDI client data used by a second EDI component of the EDI system; generating EDI client data by macro based on the relational graph and the non-EDI client data; and updating the non-EDI client data directly to a second EDI component of the EDI system through the macro.

In another embodiment, a server is disclosed for integrating non-EDI client data into an entity's EDI system, the server comprising: a processor; and a memory for storing instructions executable by the processor. The processor is configured to perform: receiving a login request from a user terminal; opening a macro provided by a server; creating a local instance of a macro on a user terminal through the macro; loading, by the macro, the client profile data from the archive to a local instance of the macro on the user terminal based on the client profile login ID; receiving, by the macro, the EDI client data from the server terminal after the user terminal generates the EDI client data based on the non-EDI client data; and updating the EDI client data directly to a second EDI component of the EDI system through the macro.

In another embodiment, a user terminal for analyzing non-EDI client data using an EDI system of an entity is disclosed, comprising: a processor; a display; and a memory for storing instructions executable by the processor. The processor is configured to perform: logging in to a server; opening a macro provided by a server; creating a local instance of a macro on a user terminal through the macro; loading, by the macro, the client profile data from the archive to a local instance of the macro on the user terminal based on the client profile login ID; receiving, by the macro on the user terminal, input of non-EDI client data on a local instance of the macro on the user system; generating EDI client data through the macro; and sending the EDI client data as an analysis result to the EDI system through the macro.

In another embodiment, a server of an entity is disclosed for analyzing non-EDI client data using an EDI system of an entity, the server comprising: a processor; and a memory for storing instructions executable by the processor. The processor is configured to perform: receiving a login request from a user terminal; opening a macro provided by a server; creating a local instance of the macro on the user terminal through the macro; loading, by the macro, the customer profile data from the archive to a local instance of the macro on the user terminal based on the customer profile login ID; and receiving, by the macro, the EDI client data from the user terminal as an analysis result after the user terminal generates the EDI client data based on the non-EDI client data.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and together with the description, serve to explain the principles of the disclosure.

Fig. 1 illustrates an example of a conventional EDI architecture between two trading companies.

Fig. 2 shows an example of an internal network of a company having an EDI system.

Fig. 3 shows an example of how EDI files in different formats are translated and converted for inbound and outbound processes in a corporate intranet.

FIG. 4A is an example of an overall structural block diagram of an OAS in accordance with an exemplary embodiment.

Fig. 4B is an example of an overall structural block diagram of an OAS designed for creating a new Purchase Order (PO) in the SAP of the EDI system according to the exemplary embodiment.

Fig. 4C is an example of an overall structural block diagram of an OAS designed for order change (remake) and confirmation in the SAP of the EDI system according to an exemplary embodiment.

FIG. 4D is an example of an overall structural block diagram of an OAS designed to make predictions in accordance with an exemplary embodiment.

5A-5B are examples of user interfaces of an OAS designed for creating a new Purchase Order (PO) according to an exemplary embodiment.

Fig. 6A-6D are flowcharts illustrating steps performed by a user terminal in order to create a new Purchase Order (PO) according to an exemplary embodiment of the present disclosure.

Fig. 7 is a flowchart illustrating steps performed by a server to create a new Purchase Order (PO) according to an exemplary embodiment of the present disclosure.

8A-8B are examples of user interfaces of an OAS designed for order change (rework) and confirmation, according to an example embodiment.

Fig. 9A-9C are flowcharts illustrating steps performed by a user terminal for order change (rework) and confirmation according to an example embodiment of the present disclosure.

10A-10B are flowcharts illustrating steps performed by a server for order change (rework) and confirmation according to an example embodiment of the present disclosure.

11A-11B are flowcharts illustrating steps performed by a user terminal for prediction according to an example embodiment of the present disclosure.

Fig. 12 is a flowchart illustrating steps performed by a server for prediction according to an exemplary embodiment of the present disclosure.

Fig. 13 is a block diagram illustrating an apparatus for integrating non-EDI customer data into an EDI system or analyzing the non-EDI customer data using the EDI system according to an exemplary embodiment of the present disclosure.

Fig. 14 is a block diagram illustrating an apparatus for integrating non-EDI customer data into an EDI system and/or analyzing the non-EDI customer data using the EDI system according to an exemplary embodiment of the present disclosure.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations set forth in the following description of exemplary embodiments do not represent all implementations consistent with the present disclosure. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present disclosure, as detailed in the appended claims.

The present disclosure provides a system and method for integrating inbound information into an EDI system that is not via the EDI system (electronic data interchange system), or otherwise making the information suitable for analysis.

For example, taiwan patent application No. 091108929, whose application date is 2002, 4, 30, discloses an order processing method for automatically receiving order data of a customer and confirming the order data according to a production schedule, which substantially comprises the following steps: receiving an EDI predicted order, performing format conversion on the EDI predicted order to generate predicted order data, and storing the predicted order data in a database; obtaining the forecast order data by accessing the database and confirming the forecast order; performing production scheduling operation on the predicted order to generate production scheduling information, and storing the production scheduling information in a database; performing format conversion to generate formal order data, and storing the formal order data in a database; and so on.

Furthermore, U.S. Pat. No. 7,984,373b2 discloses a method of creating an EDI transaction from a description of an EDI schema, which specifically includes: receiving a description of the EDI schema and other documents of the EDI schema specifying a format of the description, the received description being a non-EDI structured document; separating the non-EDI structured document from other EDI documents; identifying a plurality of data units included in the separated non-EDI structured document; classifying the identified plurality of data units as a data type; analyzing the classified plurality of data units to determine the content of the EDI schema; generating a document definition of the EDI schema; and creating an EDI transaction according to the EDI schema using the generated document definition.

The EDI systems in the prior art can only process EDI files. For the present disclosure, data/information not from an EDI file can also be integrated into an EDI system.

Generally, EDI data refers to data exchanged and automatically processed between electronic computer systems transmitted via a communication network in accordance with an agreed upon common message standard format (e.g., X12EDI, EDIFACT, etc.). For example, the EDI data may be data such as PDF, X12, TXT, XML, CSV, etc., but the present disclosure is not necessarily limited thereto. non-EDI data refers to data exchanged between electronic computer systems that is not transmitted over a communications network in accordance with an agreed upon common message standard format. For example, the non-EDI data may be data from mail or Excel, but the disclosure is not necessarily limited thereto.

Taking data/information about an order as an example, the present disclosure can integrate orders for non-EDI files into an EDI system. In other words, a non-EDI order can be changed to an EDI order and then entered into the EDI system. For the sake of brevity, the system processing orders is referred to in this disclosure as an order automation server application (OAS for short).

However, the present disclosure is not limited to processing data/information about orders and then integrating them into an EDI system, and the present disclosure can be applied to any other situation where data/information is processed and then integrated into an EDI system.

According to one example, orders are largely divided into two categories-scatter orders and general orders. The OAS is made up of multiple applications that semi-automate multiple order types throughout the lifecycle of the sales order. The plurality of applications include: creating orders, remaking orders, order confirmation, predictive analysis, predictive settlement, predictive remaking, and predictive confirmation.

According to one example, to implement the above-described application, the OAS contains as part thereof:

010 \ u CSV ORDERS to IDOC Macro for creating an order;

020_PO Update and CFM Macro for order change (rework) and confirmation;

030_SA Macro for predictive analysis, predictive accounting, predictive remaking, and predictive validation.

The CSR is the direct user of the OAS application that processes the customer's order/forecast, and the results of the OAS forecast analysis are shared with the fulfillment SE (three-dimensional computer aided design software) to understand/predict & meet the customer's business needs.

The OAS applications reconcile and integrate various non-EDI/spreadsheet-based requirements from customers into a single tool and can accommodate the customer's reluctance to switch to an EDI platform, so the OAS applications improve business continuity with their original (Excel-based) infrastructure.

The customer/CSR can make changes in the mapping each time a change is needed, thereby minimizing reliance on the EDI/research and development department/IT team.

As data-driven decision-making is a commercial need today, OAS applications are also a countermeasure to the lack of EDI when business analysis/statistical analysis is involved.

In one example, an OAS application has one or more of the following features, which can be modified by one skilled in the art based on actual needs.

Since the user/CSR can only see macros (Macro), it is a single point of access to the server.

The code is formed in a manner that only allows the server application to interact with it. This serves as an additional layer of security.

It is easily upgradeable and understandable for the user. Macro is also backward compatible.

The tool, OAS application, is widely compatible with all businesses with Microsoft Excel licensing.

The tool can generate data for EDI access.

The tool is very fast, lightweight and resource friendly because it uses the user's system resources rather than the resources of the server.

The tool is designed to operate in a read-only mode, but still enables multiple users to work on it simultaneously.

The referencing/mapping feature in some OAS applications allows the EDI team to only maintain a general map of the sales (SoldCo) level, since the user/analyst maintains complex logic in the macro directly.

In one example, the reference/map feature accommodates 12 operators (such as contain, equal, start, end, etc.) and a maximum of 3 conditions, enabling any field in the customer data to be matched with data of an entity (e.g., molex data). This gives the user, e.g., CSR, unlimited possibilities to create a relationship graph.

An archive (Profile Bank) on the server serves as a repository containing customer demand information. This removes the dependency of any particular customer data being processed by the CSR.

Instead of multiple EDI graphs for each customer demand, all demands can be handled using a single application and archive maintained directly by the customer. This saves a lot of time and money, which would otherwise require investment in the EDI/IT research and development department.

Referring to FIG. 4A, FIG. 4A illustrates an overall block diagram of an OAS according to an exemplary embodiment, which is essentially a combination of FIGS. 4B through 4D, FIGS. 4B through 4D illustrating 010, u CSV ORDERS to IDOC macros (010, u CSV ORDERS to IDOC Macro) and 020, u PO updates and CFM macros (020, u PO Update and CFM Macro), and 030, u SA Macro (030, u SA Macro), respectively.

The three macros described above are placed on the server, according to one example, on the file server, and can be accessed.

With the above macros, the vendor's EDI system is able to integrate non-EDI orders in response to a customer sending them via mail or other means, rather than via the vendor's EDI system.

In one embodiment, the OAS handles the case when the customer sends a non-EDI order directly to the supplier's CSR's private mailbox, or only verbally provides the order or changes an existing order.

As a naming convention, typically the customer object to be sold is used as the log-in name (LoginId) for archive or export file creation. In the case where a plurality of customer profiles are required for one customer object to be sold, [ SoldCo ] -1, [ SoldCo ] -2, [ SoldCo ] -3, etc. can be used as the registration names.

The dossier is stored in an OAS dossier, which may be located on the file server, and may be entered with a name such as CSR _ Order _ Automation _ profiles. The customer archive stores all customer-sensitive information and logic/mappings in a spreadsheet format on the archive. The main purpose of creating a profile for each customer is to load different configurations/mappings into the same application for different customers. Archives are typically hidden from the user, but have R/W (read/write) privileges and can be modified by load/save only through applications. The structure of the archive is the same as that of the macro spreadsheet. Saving the archive is saving the currently active worksheet as an archive catalog. Loading the archive is copying each configuration ("Init)" screen, as well as all data from other forms of the archive, to the currently active worksheet for that particular customer. The archive name may be < MacroName > _< LoginId >. Xlsm.

The three macros will be described in detail below.

Referring to FIG. 4B, 010_CSV orders to IDOC macros are used for non-EDI purchase order/determination order creation/automation.

Referring to fig. 5A and 5b,010_csv orders to IDOC macros provide the following tabs/screens for user terminals of CSRs:

instruction tag/screen

The screen contains a guide for the use of the tool. The CSR can simply follow the instructions and use the customer-supplied non-EDI data to get a new order to be placed in the SAP.

Initial tab/screen

The screen contains the parameters needed to map the user-supplied data to the vendor's data format (e.g., known as Molex universal data). As an example, molex generic data may be in Comma Separated Value (CSV) format. The field values in the screen are stored in columns B, G, and H of the screen. A field will typically store two types of values:

default Value (DVAL) -this is the value used in the "CSV ORDER to IDO (CSV ORDER to IDO)" screen when the customer has not yet provided data.

First Reference (FREE) -this field points to the first cell of the column in the customer data. For example, if the value of "contact-first reference" is D2 in the "initial" screen, it means that the customer has entered into the contact data of the D column from Row (Row) 2 in the "New PO" screen. If reference is made to FREF, it has priority over DVAL.

Note that: this value can be mandatory (red) or optional (black).

In the "initial" screen, if any of the first 5 mandatory values-sales organization, order team, delivery location, order type and lot have multiple values, the corresponding fields should remain blank and a relationship graph must be defined in the "reference" screen. As an example, the user has the option of providing three conditions to match each record from the customer data to its corresponding record in Molex universal data.

Reference tag/screen

This screen may be used when multiple orders, delivery locations, payers, sales organizations, buyers, order types, and lots are used by the same customer. This creates a relationship graph to translate each record from the customer into its corresponding Molex generic data. This Generic data is the input to the Generic map "FES _ CSV-ORDERS _ Inbound _ Generic" or "FES _ CSV-ORDERS _ OnESOPErLine _ Inbound _ Generic" in the EDI Sterling integrator. The relationship graph is maintained directly by the CSR.

New PO label/screen

Data received from the customer must be placed there by the CSR.

CSV order to IDOC (CSV ORDERS to IDOC) tab/screen

The 010_CSV order to IDOC macro generates this screen using the data from the new PO, the initial table, and the reference table. The data generated in this screen is saved as a CSV file into an output folder and then sent by mail to the SI to create an order in the system.

Once all mandatory information is automatically populated/first entered by the CSR using the existing profile, the button "prepare CVS order to create a new PO in SAP" is clicked and the customer specific data in the "New PO" screen is translated into Molex generic data in the "CVS order to IDOC" screen.

Referring to fig. 5A and 5B, once the data on the "CVS order to IDOC" screen is ready to be sent to the Sterling Integrator (SI), the CSR selects the value "system update" and then clicks the button "send CSV order file as mail" to send the data to the SI of the EDI system.

Fig. 6A-6D are flowcharts illustrating steps performed by a user terminal of a CSR in order to create a new Purchase Order (PO) according to an exemplary embodiment of the present disclosure.

The user terminal may be a smart device having a Universal Serial Bus (USB), such as a smart phone, a notebook computer, a Personal Digital Assistant (PDA), or the like. A user terminal for creating a new EDI Purchase Order (PO) in an EDI system by integrating non-EDI customer data (non-EDI purchase order data) into the EDI system of an entity (e.g., a supplier), the user terminal comprising:

a processor;

a display; and

a memory for storing instructions executable by the processor;

wherein the processor is configured to perform a method comprising:

step 101: logging in to a server;

step 103: opening a Macro provided by a server (Order Creation Macro);

step 105: creating a local instance of a macro on a user terminal through the macro;

step 107: receiving data of a customer profile through a macro;

step 109: obtaining, by the macro, on a local instance of the macro on the user terminal, a relationship diagram between non-EDI client data and formats of the non-EDI client data and EDI client data used by a first EDI component (SI) of the EDI system (according to one example, the format of the EDI client data is in CSV format, i.e., "Molex universal data");

step 111: generating EDI client data by macro based on the relational graph and the non-EDI client data;

step 113: the EDI client data is transmitted to a server, which integrates the EDI client data into a first EDI component (SI) of the EDI system.

The entity is a supplier, the non-EDI customer data is a non-EDI order from mail or Excel, and the EDI customer data is in CSV format.

The step 113 of transmitting the EDI client data to the server includes: the CSV order is saved to the server by the macro, and the server sends the CSV order to a first EDI component (SI) of the EDI system by mail.

According to one example, a local instance of a macro is provided with a user interface; the step 109 of obtaining by the macro a relationship diagram between the non-EDI client data and the format of the EDI client data used by the first EDI component includes:

step 109-1: receiving a user's input via an INIT screen displayed on a user interface to create a relationship graph;

step 109-3: receiving input of non-EDI customer data from the user via a new PO screen displayed on the user interface; and

the step 111 of generating EDI client data by the macro based on the relationship graph and the non-EDI client data comprises:

step 111-1: the CSV order is generated based on the relationship graph and the non-EDI customer data via the CVS order to IDOC screen displayed on the user interface.

According to another example, the local instance of the macro is provided with a user interface, and the step 109 of obtaining by the macro a relationship graph between the non-EDI client data and the format of the EDI client data used by the first EDI component comprises:

step 109-1': receiving input from a user via an INIT screen displayed on a user interface to create a first relationship diagram between a format of non-EDI client data and a format of EDI client data;

step 109-2': receiving an input of a user via a reference screen displayed on a user interface to create a second relationship diagram between a format of the non-EDI client data and a format of the EDI client data if the mandatory field of the INIT screen has more than one value;

step 109-3': receiving user-entered non-EDI customer data via a new PO screen displayed on the user interface; and

by the macro, the step 111 of generating the EDI client data based on the relationship diagram between the non-EDI client data and the EDI client data includes:

step 111-1': a CSV order is generated based on the first and second relationship maps and the non-EDI customer data via a CVS order to IDOC screen displayed on the user interface.

According to another example, the step 107 of receiving customer profile data by the macro comprises:

step 107-1: receiving a user's selection of options for setting using an existing customer profile and for manually making the setting;

step 107-2: whether an existing customer profile is found in the archive;

step 107-3: if so, loading data from the archive to a local instance of the macro on the user terminal based on the client archive login ID; and

step 107-5: if not, a local instance of a macro entered by the user on the user terminal is received.

A server for creating a new EDI Purchase Order (PO) in an EDI system by integrating non-EDI customer data (non-EDI purchase order data) into the EDI system of an entity, such as a supplier, the server comprising:

a processor;

a display; and

a memory for storing instructions executable by the processor;

wherein the processor is configured to perform a method comprising:

step S201: receiving a login request from a user terminal;

step S203: opening a server-provided macro (order creation macro);

step S205: creating a local instance of the macro on the user terminal through the macro;

step S207: loading, by the macro, the customer profile data from the archive to a local instance of the macro on the user terminal based on the customer profile login ID;

step S209: after the user terminal generates EDI client data based on the non-EDI client data, receiving the EDI client data of the user terminal through a macro;

step S211: the EDI customer data is integrated into a first EDI component (SI) of the EDI system.

Referring to FIG. 4C,020 (R) u PO update and CFM macro are used for non-EDI purchase order/rework/confirmation of certain orders.

The 020\ u PO update and CFM macro provide the following screens for the user terminal of the CSR:

init label/screen

This screen contains the parameters needed to map the customer-supplied data and the Molex SAP system data. The field values will be stored in columns B, G and H of the screen. Note that: the value may be mandatory (red) or optional (black).

The screen is divided into four parts:

1) And (3) controlling reference: this section includes the main parameters that enable the application to understand the output requirements of the user.

According to one example, the fields found under this section are:

update VA02 using SO #? (yes/no) -if yes, then SAP update uses SO #, otherwise PO # and SoldTO are used.

Block order-a CSR can be selected to apply or remove the delivery block for all rows it wants to update in the SAP.

2) Customer opens outstanding order reference: this section contains a column indication/reference to the customer's outstanding order data. For example, if the user has provided a PO #, in the "A" column, the field will contain "A2" which is the first PO value in the customer data.

3) Molex incomplete order referencing: this section contains column indications/references to Molex incomplete orders. For example, if the Molex SAP data excerpt (extract) has a PO #, in the "A" column, the field will contain "A2" which is the first PO value in the Molex data.

4) Previous customer opens outstanding order references: this section contains a column indication/reference to the last week customer outstanding order data. For example, if the user has provided a PO #, in the "A" column, the field will contain "A2" which is the first PO value in the customer data.

Molex opens outstanding order tab/screen

The actual data presented in the Molex SAP for the customer is extracted by the CSR.

Customer opens outstanding order tab/screen

Data received from the customer must be placed there by the CSR.

Previous customer opens outstanding order tab/screen

Data received from customers in the last week must be placed there by the CSR. The tab/screen is selectable.

VA02 tag/screen

This may be the output of the macro but is not required. Once the "execute" button is clicked, the data generated on the screen is updated to the SAP.

The steps are as follows. And loading the client file. The archive is loaded in the same way as all other macros.

The CSR copies the existing data of the last week on the "customer open outstanding orders" screen to the "previous customer open outstanding orders" screen, but this is not required.

The CSR enters non-EDI customer data into a "customer opens outstanding orders" screen.

The CSR extracts the existing data for the customer from the SAP into a "Molex open outstanding orders" screen.

Referring to fig. 8a, the csr enters all the required information about all parts of the "initial" screen-the customer open outstanding order reference, the control reference, the Molex outstanding order reference, and the previous customer open outstanding order reference (in the case where data is presented and there is a business need for analysis in the PO confirmation).

Once all of the above steps are completed, the CSR clicks on the "PO Change Macro" on the initial screen and/or then clicks on the "PO confirm Macro" button. This initiates a PO change and/or subsequent PO validation execution. According to a further example, a Pivot table (Pivot table) is generated. All analysis is completed and the flag is updated in the customer open outstanding orders screen. After analyzing and updating the markers, the clients that match their respective Molex records and meet the criteria selected in the initial screen open these arrows in the outstanding orders are moved to VA02 for updating in the SAP.

Referring to fig. 8B, once the CSR clicks the execute button on the VA02 screen, if the existing SAP session is open, a script is executed that updates the purchase order/sales order in the SAP. The application gives an error if there is no corresponding SAP session opened. After updating the SAP for all table rows in the VA02 screen, control returns to the application with the success/check message.

Fig. 9A-9C are flowcharts illustrating steps performed by a user terminal of a CSR for order change (rework) and confirmation according to an example embodiment of the present disclosure.

The user terminal may be a smart device having a Universal Serial Bus (USB), such as a smart phone, a notebook computer, a Personal Digital Assistant (PDA), and the like. The user terminal implements order change (reproduction) and confirmation by integrating non-EDI customer data (non-EDI purchase order data) into the EDI system of one entity.

The user terminal may implement the order creation above and the order change (remake) and confirmation described below.

The user terminal includes:

a processor;

a display; and

a memory for storing instructions executable by the processor;

wherein the processor is configured to perform a method comprising:

step 301: logging in to a server;

step 303: open server-provided macros (order change and confirmation macros);

step 305: creating a local instance of a macro on a user terminal through the macro;

step 307: loading, by the macro, the customer profile data from the archive to a local instance of the macro on the user terminal based on the customer profile login ID;

step 309: obtaining, by the macro, a relationship diagram between the formats of the non-EDI client data and the format of the EDI client data used by a second EDI component (SAP) of the EDI system, on a local instance of the macro on the user terminal;

step 311: generating EDI client data based on the relationship graph and the non-EDI client data through the macro;

step 313: through the macro, EDI client data is updated directly to a second EDI component (SAP) of the EDI system.

The step 313 of directly updating the EDI client data by the macro includes:

step 313-1: through the macro, a session (SAP session) is opened with a second EDI component of the EDI system connected to the vendor's own internal information system.

Step 313-2: through the macro, EDI client data is changed or validated directly to a second EDI component (SAP) of the EDI system.

The step 309 of obtaining by the macro a relationship diagram between the non-EDI client data and the format of the EDI client data used by the second EDI component includes:

step 309-1: receiving a user's input via an INIT screen displayed on a user interface to create a relationship graph;

step 309-3: receiving EDI client data of an existing EDI order from a second EDI component (SAP) via an open outstanding orders screen (Molex open outstanding orders) displayed on a user interface;

step 309-5: receiving non-EDI customer data via a customer open outstanding orders screen displayed on a user interface; and

the step 311 of generating EDI client data by macro based on the relationship graph and the non-EDI client data comprises:

step 311-1: and correspondingly executing the change or confirmation of the EDI client data through the PO change macro or the PO confirmation macro on the INIT screen.

The server may implement the order creation above and the order change (rework) and confirmation described below.

The server includes:

a processor;

a display; and

a memory for storing instructions executable by the processor;

wherein the processor is configured to perform a method comprising:

step 401: receiving a login request from a user terminal;

step 403: open server-provided macros (order change and confirmation macros);

step 405: creating a local instance of the macro on the user terminal through the macro;

step 407: loading, by the macro, the customer profile data from the archive to a local instance of the macro on the user terminal based on the customer profile login ID;

step 409: receiving, by a macro, EDI client data from a user terminal after the user terminal generates EDI client data based on non-EDI client data;

step 411: through the macro, the EDI client data is directly updated into a second EDI component of the EDI system.

The step of directly updating the EDI client data by the macro includes:

step 411-1: opening, by the macro, a session (SAP session) with a second EDI component of the EDI system connected to the vendor's own internal information system; and

step 411-3: through the macro, the EDI client data is changed or validated directly to a second EDI component of the EDI system.

Referring to fig. 4d 030, u SA macro (forecast) is used to automate the commitment of forecast analysis, settlement, management, non-EDI bulk SA orders. It analyzes, tracks the customer's trends, proposes plans with quantities, and finally uploads the data to the SAP.

11A-11B are flowcharts illustrating steps performed by a user terminal to forecast an order according to an exemplary embodiment of the present disclosure.

The user terminal may implement the above order creation, order change (remake) and confirmation, as well as the prediction described below.

The user terminal includes:

a processor;

a display; and

a memory for storing instructions executable by the processor;

wherein the processor is configured to perform a method comprising:

step 501: logging in to a server;

step 503: opening a server-provided macro (SA macro);

step 505: creating a local instance of a macro on a user terminal through the macro;

step 507: loading, by the macro, the client profile data from the archive to a local instance of the macro on the user terminal based on the client profile login ID;

step 509: receiving, by a macro on a user terminal, input of non-EDI client data on a local instance of the macro on the user system;

step 511: generating EDI client data through the macro;

step 513: and sending the EDI client data as an analysis result to the EDI system through the macro.

The step 513 of transmitting the EDI client data as the analysis result to the EDI system through the macro includes at least one of the following steps:

step 513-1: storing the EDI client data to a server through a macro; and

step 513-3: the EDI client data is sent directly to a second EDI component (SAP) of the EDI system by the macro.

Fig. 12 is a flowchart illustrating steps performed by a server to forecast an order according to an exemplary embodiment of the present disclosure.

The server may implement the order creation above, order change (rework) and confirmation, and the forecasting described below.

The server includes:

a processor;

a display; and

a memory for storing instructions executable by the processor;

wherein the processor is configured to perform a method comprising:

step 601: receiving a login request from a user terminal;

step 603: opening a server-provided macro (SA macro);

step 605: creating, by a macro, a local instance of the macro on a user terminal;

step 607: loading, by the macro, the customer profile data from the archive to a local instance of the macro on the user terminal based on the customer profile login ID;

step 609: after the user terminal generates the EDI client data based on the non-EDI client data, the EDI client data from the user terminal is received through the macro.

Referring to fig. 13, apparatus 1300 may be a user terminal including one or more of the following components: a processing component 1302, a memory 1304, a power component 1306, a multimedia component 1308, an audio component 1310, an input/output (I/O) interface 1312, a sensor component 1314, and a communications component 1316.

The processing component 1302 generally controls overall operation of the apparatus 1300, such as operations associated with display, telephone calls, data communications, camera operations, and recording operations. The processing component 1302 may include one or more processors 1320 to execute instructions to perform all or part of the steps of the methods described above. Further, processing component 1302 can include one or more modules that facilitate interaction between processing component 1302 and other components. For example, the processing component 1302 may include a multimedia module to facilitate interaction between the multimedia component 1308 and the processing component 1302.

The memory 1304 is configured to store various types of data to support operations at the apparatus 1300. Examples of such data include instructions for any application or method operating on device 1300, contact data, phonebook data, messages, pictures, videos, and so forth. The memory 1304 may be implemented by any type or combination of volatile or non-volatile storage devices such as Static Random Access Memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic or optical disks.

Power supply component 1306 provides power to the various components of device 1300. The power components 1306 may include a power management system, one or more power supplies, and any other components associated with the generation, management, and distribution of power in the apparatus 1300.

The multimedia components 1308 include screens that provide an output interface between the device 1300 and a user. In some embodiments, the screen may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive an input signal from a user. The touch panel includes one or more touch sensors to sense touch, slide, and gestures on the touch panel. The touch sensor may not only sense the boundary of a touch or slide action, but also detect the duration and pressure associated with the touch or slide operation. In some embodiments, the multimedia component 1308 includes a front facing camera and/or a rear facing camera. The front-facing camera and/or the back-facing camera may receive external multimedia data when the device 1300 is in an operational mode, such as a capture mode or a video mode. Each front camera and rear camera may be a fixed optical lens system or have a focal length and optical zoom capability.

The audio component 1310 is configured to output and/or input audio signals. For example, the audio component 1310 includes a Microphone (MIC) configured to receive an external audio signal when the apparatus 1300 is in an operational mode, such as a call mode, a recording mode, and a voice recognition mode. The received audio signal may further be stored in the memory 1304 or transmitted via the communication component 1316. In some embodiments, audio component 1310 also includes a speaker for outputting audio signals.

The I/O interface 1312 provides an interface between the processing component 1302 and peripheral interface modules, which may be keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to: a home button, a volume button, a start button, and a lock button.

The sensor assembly 1314 includes one or more sensors for providing various aspects of state assessment for the device 1300. For example, the sensor assembly 1314 may detect an open/closed state of the device 1300, relative positioning of components of the apparatus 1300 (e.g., a display and keypad), a change in position of the apparatus 1300 or components of the apparatus 1300, the presence or absence of user contact with the apparatus 1300, orientation or acceleration/deceleration of the apparatus 1300, and a change in temperature of the apparatus 1300. The sensor assembly 1314 may include a proximity sensor configured to detect the presence of a nearby object without any physical contact. The sensor assembly 1314 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, the sensor assembly 1314 may also include an acceleration sensor, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

The communication component 1316 is configured to facilitate communications between the apparatus 1300 and other devices in a wired or wireless manner. The apparatus 1300 may access a wireless network based on a communication standard, such as WiFi, 2G, 3G, or 4G cellular technologies, or a combination thereof. In an exemplary embodiment, the communication component 1316 receives broadcast signals or broadcast related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communications component 1316 also includes a Near Field Communication (NFC) module to facilitate short-range communications. For example, the NFC module may be implemented based on Radio Frequency Identification (RFID) technology, infrared data association (IrDA) technology, ultra Wideband (UWB) technology, bluetooth (BT) technology, and other technologies.

In an exemplary embodiment, the apparatus 1300 may be implemented with one or more Application Specific Integrated Circuits (ASICs), digital Signal Processors (DSPs), digital Signal Processing Devices (DSPDs), programmable Logic Devices (PLDs), field Programmable Gate Arrays (FPGAs), controllers, micro-controllers, microprocessors or other electronic components for performing the above-described methods.

In an exemplary embodiment, a non-transitory computer readable storage medium comprising instructions, such as the memory 1304 comprising instructions, executable by the processor 1320 of the apparatus 1300 to perform the method described above is also provided. For example, the non-transitory computer readable storage medium may be a ROM, a Random Access Memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, and the like.

Fig. 14 is a block diagram of another apparatus 400 for suggesting a wireless connection according to an example embodiment of the present disclosure. For example, the apparatus 1400 may be a server. Referring to fig. 14, the apparatus 1400 includes a processing component 1422 that further includes one or more processors and storage resources, represented by memory 1432, for storing instructions, such as applications, that are executable by the processing component 1422. The application programs stored in memory 1432 may include one or more modules, each module corresponding to a set of instructions. Moreover, the processing component 1422 is configured to execute instructions to perform the above-described methods for integrating and/or analyzing non-EDI customer data into and/or with an EDI system.

The device 1400 may also include a power component 1426 configured to perform power management for the device 1400, a network interface 1450 configured to connect the device 1400 to a network or another device, and an input/output (I/O) interface 1478. The apparatus 1400 may operate based on an operating system stored in memory, such as Windows Server, mac OS XTM, unixTM, linuxTM, freeBSDTM, and so forth.

It will be understood that the invention is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the invention is only limited by the appended patent claims.

Claims

1. A user terminal for integrating non-EDI customer data into an entity's EDI system, said user terminal comprising:

a processor;

a display; and

a memory for storing instructions executable by the processor;

wherein the processor is configured to perform:

logging in to a server;

opening a macro provided by a server;

creating, by the macro, a local instance of the macro on the user terminal;

receiving, by the macro, a client profile entry ID indicating a corresponding commonality map of sales (SoldCo) degrees and reference/mapping characteristics maintained by the commonality map of sales (SoldCo) degrees; obtaining, by the macro on a local instance of the macro on the user terminal, a relationship graph created by the referencing/mapping feature between formats of non-EDI client data and a format of EDI client data used by a first EDI component of the EDI system;

generating, by the macro, EDI client data based on the relationship graph and the non-EDI client data; and

transmitting the EDI client data to the server, the server integrating the EDI client data into the first EDI component of the EDI system.

2. The user terminal of claim 1,

the entity is a supplier, the non-EDI customer data is a non-EDI order from mail or Excel, and the EDI customer data is a CSV order.

3. The user terminal of claim 2, wherein transmitting the EDI client data to the server comprises:

saving the CSV order to the server through the macro, the server sending the CSV order to the first EDI component of the EDI system through mail.

4. The user terminal of claim 3,

the local instance of the macro is provided with a user interface;

obtaining, by the macro, non-EDI client data and a relationship graph created by the referencing/mapping feature between the format of the non-EDI client data and the format of the EDI client data used by the first EDI component includes:

receiving input of a user via an INIT screen displayed on the user interface to create the relationship graph;

receiving the non-EDI customer data input by a user via a new PO screen displayed on the user interface; and is

Generating, by the macro, EDI client data based on the relationship graph and the non-EDI client data comprises: generating the CSV order based on the relationship graph and the non-EDI customer data via a CVS order to IDOC screen displayed on the user interface.

5. The user terminal of claim 3,

the local instance of the macro is provided with a user interface;

receiving input from a user via an INIT screen displayed on the user interface to create a first relationship diagram between the format of the non-EDI client data and the format of EDI client data;

receiving user input via a reference screen displayed on the user interface to create a second relationship diagram between the format of the non-EDI client data and the format of the EDI client data if the mandatory field of the INIT screen has more than one value;

receiving the non-EDI client data input by a user via a new PO screen displayed on the user interface; and is

Generating EDI client data by the macro based on the relationship graph between the non-EDI client data and the EDI client data comprises: generating the CSV order based on the first and second relationship graphs and the non-EDI customer data by displaying a CVS order to IDOC screen on the user interface.

6. A server for integrating non-EDI client data into an entity's EDI system, said server comprising:

a processor; and

a memory for storing instructions executable by the processor;

wherein the processor is configured to perform:

receiving a login request from a user terminal;

opening a macro provided by the server;

creating, by the macro, a local instance of the macro on the user terminal;

loading, by the macro, client profile data from a profile repository to the local instance of the macro on the user terminal based on a client profile login ID, the client profile login ID indicating a generic map of corresponding sales (SoldTo) degrees and a reference mapping feature maintained by the generic map of sales (SoldTo) degrees;

receiving, by the macro, EDI client data of the user terminal after the user terminal generates EDI client data based on a relationship graph created by the referencing/mapping feature and non-EDI client data between a format of the non-EDI client data and a format of the EDI client data used by a first EDI component of the EDI system; and

integrating the EDI customer data into a first EDI component of an EDI system.

7. The server of claim 6, wherein,

8. The server of claim 7, wherein integrating the EDI client data into an EDI system comprises:

sending the CSV order to a first EDI component of the EDI system by mail.

9. A user terminal for integrating non-EDI customer data into an entity's EDI system, said user terminal comprising:

a processor;

a display; and

a memory for storing instructions executable by the processor;

wherein the processor is configured to perform:

logging in a server;

opening a macro provided by the server;

creating, by the macro, a local instance of the macro on the user terminal;

loading, by the macro, client profile data from a profile repository to the local instance of the macro on the user terminal based on a client profile login ID, the client profile login ID indicating a generic map of corresponding sales (SoldTo) degrees and a reference/mapping feature maintained by the generic map of sales (SoldTo) degrees;

obtaining, by the macro, on the local instance of the macro on the user terminal, a relationship graph created by the referencing/mapping feature between formats of non-EDI client data and a format of EDI client data used by a second EDI component of an EDI system;

updating the EDI client data directly into the second EDI component of the EDI system through the macro.

10. The user terminal of claim 9,

the entity is a supplier; and

directly updating the EDI client data by the macro includes:

opening, by the macro, a session with the second EDI component of the EDI system, the EDI system connected to the vendor's own internal information system; and

changing or validating the EDI client data directly to the second EDI component of the EDI system through the macro.

11. The user terminal of claim 10,

the local instance of the macro is provided with a user interface;

obtaining, by the macro, a relationship graph created by the referencing/mapping feature between the formats of the non-EDI client data and the format of the EDI client data used by the second EDI component includes:

receiving the EDI customer data for an existing EDI order from the second EDI component via an open outstanding orders screen displayed on the user interface;

receiving the non-EDI customer data via an open outstanding orders screen displayed on the user interface; and is

Generating, by the macro, EDI client data based on the relationship graph and the non-EDI client data comprises: the change or confirmation of the EDI client data is correspondingly performed via a PO change macro or a PO confirmation macro on the INIT screen.

12. A server for integrating non-EDI customer data into an entity's EDI system, said server comprising:

a processor; and

a memory for storing instructions executable by the processor;

wherein the processor is configured to perform:

receiving a login request from a user terminal;

opening a macro provided by the server;

creating, by the macro, a local instance of the macro on the user terminal;

loading, by the macro, client profile data from a profile repository to the local instance of the macro on the user terminal based on a client profile login ID, the client profile login ID indicating a corresponding commonality map of degree of sales (SoldTo) and a reference/mapping feature maintained by the commonality map of degree of sales (SoldTo);

receiving, by the macro, EDI client data from the user terminal after the EDI client data is generated by the non-EDI client data and a relational map created by the referencing/mapping feature between a format of the non-EDI client data and a format of EDI client data used by a second EDI component of the EDI system; and

directly updating the EDI client data to a second EDI component of the EDI system through the macro.

13. The server of claim 12, wherein,

the entity is a supplier; and

directly updating the EDI client data by the macro includes:

opening, by the macro, a session with a second EDI component of the EDI system, the EDI system being connected to the supplier's own internal information system; and

changing or validating the EDI client data directly to the second EDI component through the macro.

14. A user terminal for analyzing non-EDI client data using an entity's EDI system, said user terminal comprising:

a processor;

a display; and

a memory for storing instructions executable by the processor;

wherein the processor is configured to perform:

logging in a server;

opening a macro provided by the server;

creating a local instance of a macro on the user terminal by the macro;

receiving, by the macro on the user terminal, input non-EDI client data on the local instance of the macro on the user system;

generating, by the macro, EDI client data based on a relational graph created by the referencing/mapping characteristics between a format of non-EDI client data and a format of EDI client data; and

and sending the EDI client data as an analysis result to an EDI system through the macro.

15. The user terminal of claim 14,

the entity is a supplier, the non-EDI customer data is a non-EDI batch SA order, and the EDI customer data is in a CSV format.

16. The user terminal of claim 15, wherein transmitting the EDI client data as the analysis result to the EDI system through the macro comprises at least one of:

storing the EDI client data to the server by the macro; and

sending, by the macro, the EDI client data directly to a second EDI component of the EDI system.

17. A server for analyzing non-EDI client data using an EDI system of an entity, said server comprising:

a processor; and

a memory for storing instructions executable by the processor;

wherein the processor is configured to perform:

receiving a login request from a user terminal;

opening a macro provided by a server;

creating a local instance of the macro on the user terminal through the macro;

loading, by the macro, client profile data from a profile repository to the local instance of the macro on the user terminal based on a client profile login ID, the client profile login ID indicating a corresponding commonality map of degree of sales (SoldTo) and a reference/mapping feature maintained by the commonality map of degree of sales (SoldTo); and

receiving, by the macro, the EDI client data as an analysis result from the user terminal after the user terminal generates the EDI client data based on the non-EDI client data and the relationship diagram created by the referencing/mapping characteristic between the format of the non-EDI client data and the format of the EDI client data.

18. The server of claim 17, wherein,

the entity is a supplier, the non-EDI customer data is a non-EDI order from an email or Excel, and the EDI customer data is in a CSV format.

19. The server of claim 18, further comprising at least one of the following steps after receiving EDI client data as an analysis result from the user terminal through the macro:

sending the EDI client data to an email to be sent to the client by the user through the macro;

automatically extracting the non-EDI client data into a main wave report in a sharing platform through the macro; and

receiving, by the macro, the EDI client data to a first EDI component of the EDI system;

uploading the EDI client data directly to a second EDI component of the EDI system through the macro.