TW201902184A - Device for processing data that is not electronically exchanged - Google Patents

Abstract

A device applicable for processing data of non-electronic data interchange format. The device is arranged to integrate client data with non-electronic data interchange format into an entity of electronic data interchange system, and to use the electronic data interchange system to analyze the client data with non-electronic data interchange format. The device loads client's file, and provides user a user interface for inputting the client data with non-electronic data interchange format, and for inputting a relationship diagram illustrating the data with non-electronic data interchange format and the data with electronic data interchange format in the electronic data interchange system. The device generates the data with electronic data interchange format for inputting to the electronic data interchange system.

Description

Device for processing non-electronic data interchange

The present invention relates to the exchange of data between different devices, and in particular to a method for integrating information that is inbound without going through an EDI system (electronic data interchange system) into an EDI system and / or processing the information to make it suitable for analysis / Device for statistical analysis.

EDI (Electronic Data Interchange) is a standard method of electronic communication used to exchange data via any electronic means. By following the same standards, two different companies or organizations can electronically exchange files (such as purchase orders, bills, shipping notices, and many other documents) even in two different countries. There are many EDI standards (including X12 EDI, EDIFACT, etc.), some of them address the needs of specific industries or regions. The standard is used to make EDI a "machine-to-machine interaction for strictly formatted messages." Therefore, EDI can be formally defined as: through the agreed message standards, no manual intervention is required to transfer structured data from one computer system to another. EDI can be transmitted using any method agreed upon by the sender and receiver. This includes multiple technologies, including modems (asynchronous and synchronous), electronic mail (e-mail), file transfer protocol (FTP), hypertext transfer protocol (HTTP), AS1, AS2, AS4, and more. More and more trading partners use the network for transmission, that is, to transmit EDI files via email. Trading partners can interact directly or through an intermediary such as a value-added network (VAN). EDI files often contain the same information, which can often be found in paper files for the same organizational functions. For example, a manufacturer uses an EDI 940 order from the warehouse to the ship to tell the retailer the product from the warehouse to the ship. It usually has a list of "ship to" addresses, "payer" addresses, and product numbers (usually Universal Product Code (UPC)) and quantities. Another example is the setting of messages between the seller and the buyer, such as a quote invitation (RFQ), RFQ-responsive bids, purchase orders, purchase order confirmations, shipping notices, receipt notices, bills, and payment notices. However, EDI is not limited to only trade-related business information, but encompasses all areas such as medicine (such as patient records and experimental results), transportation (such as container and shipping information), engineering, and construction. Referring to FIG. 1, FIG. 1 shows an example of a traditional EDI architecture for exchanging EDI files between two trading companies using an EDI system, with a value-added network (VAN for short) between them. Each company's EDI system includes a communication device for receiving EDI files, and an EDI conversion device for translating and converting EDI files into a format that can be input into the company's own internal information system. For the "outbound" file, the EDI system will output the file (or read the database) from the company's internal information system or ERP (Enterprise Resource Planning), and convert the file into a format suitable for the translator. The translator (usually translation software) will then "verify" the file to ensure that it meets the standards agreed by the trading partner, convert the file to "EDI" format (add the appropriate identifier and control structure) and use the appropriate protocol to convert the file Send to trading partners, indirectly via VAN or directly using protocols such as FTP or AS2. For the "inbound" file, the EDI system will receive the EDI file indirectly via the VAN or directly using protocols such as FTP or AS2, obtain the received EDI file, and verify that the trading partner that sent the EDI file is a valid trading partner. The corresponding fields of EDI standard and information conversion are in accordance with the agreed agreement. Usually, the first step is to receive the EDI file from the mailbox via a translator, which will create a fixed-length or variable-length file or a format tagged with XML. The next step is to convert / transform the file, and the translator creates the file into a format that can be imported into the company's own internal information system or ERP. This can be achieved through the use of custom programs, integrated proprietary "mappers", or graphical "mappers" based on integrated standards, using a standard data transformation language such as XSLT. The final step is to enter the converted files into the company's own internal information system. For example, referring to Figure 2 and the upper part of Figure 3, for the "inbound" process, the company's translator can be an IBM product, namely Sterling B2B integrator (referred to as SI), which will be sent from the EDI mail server / file Files received by the server in EDI format, such as X12, TXT, XML, CSV, etc., are converted into SAP IDOC format. Then, the company's conversion software, such as SAP AG's product SAP system, converts the files in SAP IDOC format into a format that can be imported into the company's own internal information system, and finally enters the converted files into the company's own internal information system. . A very important advantage of the EDI system is the speed with which trading partners receive information from the EDI file and integrate it into their own internal systems. However, quite a few trading partners are unwilling to switch to the EDI platform, so they still send non-EDI files, causing their partners to integrate information slowly and with a high probability of error. As an example, orders are common for trading partners such as suppliers and their customers. Orders include purchase orders, modification orders, and forecast orders. It is common for the client company to have the original (Excel-based) infrastructure, and its employees are used to sending Excel orders to suppliers using the EDI system. The person responsible for the order in the supplier, such as a customer service representative (CSR for short), will 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 means low efficiency and high repetition rate and means high error rate. In addition, since it is very convenient to send emails using any PC or handheld device such as a mobile phone, many customers send orders to the CSR in the supplier via email, which results in slow integration of information and high error rates. In addition, because the customer will change the order many times by mail or just by phone, the CSR in the supplier will have to manually read the information of the mail or record the content of the phone, and change the information and content each time in the supplier's own system . Moreover, they will often have to turn to their own company's EDI / R & D department / IT team to change the mapping so that they can change this information. Regardless of whether the format of non-EDI orders is Excel, other forms or emails, or even just phone calls, there are a variety of customer needs that need to be entered into the supplier's own system, including the content / layout agreed between the customer and the supplier / Format terms and conditions. In addition, the need for business analysis / statistical analysis using a variety of data is growing. The data / information input into the supplier's own system through the EDI system can be easily used for analysis / statistical analysis, but not the data / information without the EDI system.

The summary provided by the present invention introduces the selection of concepts in a concise form, and the selection of the concepts is further described in the description below. This summary is not intended to identify key features or important features of the claimed subject matter. Nor is it intended to limit the scope of the claimed subject matter. In one embodiment, a user terminal is provided for integrating non-EDI customer data into a physical EDI system. The user terminal includes: a processor; a display; and a memory for storing Instructions executed by the processor. The processor is configured to execute: log on to the server; open the macro provided by the server; use the macro to create a local instance of the macro on the user terminal; receive the customer profile data through the macro; and on the user terminal On the local instance of the macro, the relationship between the format of the non-EDI customer data and non-EDI customer data and the format of the EDI customer data used by the first EDI system component of the EDI system is obtained through the macro; , Generating EDI customer data based on the relationship diagram and non-EDI customer data; sending the EDI customer data to a server, and the server integrating the EDI customer data into a first EDI component of the EDI system. In another embodiment, a server is provided for integrating non-EDI client data into a physical EDI system. The server includes: a processor; and a memory for storing the executable by the processor. Instructions. The processor is configured to execute: receive a login request from a user terminal; open a macro provided by the server; create a local instance of the macro on the user terminal through the macro; receive customer profile information through the macro; The macro, based on the customer profile login ID, loads customer profile data from the archive to the local instance of the macro on the user terminal; and generates EDI on the user terminal based on non-EDI customer data After the customer data, receiving EDI customer data from the user terminal; and integrating the EDI customer data into a first EDI component of an EDI system. In another embodiment, it provides a user terminal for integrating non-EDI customer data into a physical EDI system, which includes: a processor; a display; and a memory for storing executable by the processor Instructions. The processor is configured to execute: log in to the server; open the macro provided by the server; create a local instance of the macro on the user terminal through the macro; use the macro to log the client based on the client profile login ID The file data is loaded into the local instance of the macro on the user terminal from the archive; the format of the non-EDI customer data and non-EDI customer data obtained by the macro from the local instance of the macro of the user terminal is obtained by the EDI. The relationship diagram between the formats of the EDI customer data used by the second EDI component of the system; the generation of EDI customer data based on the relationship graph and the non-EDI customer data by the macro; and the direct update of the non-EDI customer data to the EDI system through the macro Second EDI element. In another embodiment, a server is provided for integrating non-EDI client data into a physical EDI system. The server includes: a processor; and a memory for storing instructions executable by the processor. . The processor is configured to execute: receive a login request from a user terminal; open a macro provided by the server; create a local instance of the macro on the user terminal through the macro; and use the macro to convert the client profile data based on the client profile login ID A local instance of the macro loaded from the archive onto the user terminal; after the user terminal generates EDI customer data based on non-EDI customer data, the EDI customer data is received from the server terminal through the macro; EDI customer data is updated to the second EDI component of the EDI system. In another embodiment, a user terminal for analyzing non-EDI customer data using an entity's EDI system is provided, which includes: a processor; a display; and a memory for storing instructions executable by the processor. . The processor is configured to execute: log on to the server; open the macro provided by the server; use the macro to create a local instance of the macro on the user terminal; use the macro to load the customer profile data from the archive based on the client profile login ID A local instance of the macro entered on the user terminal; receiving input of non-EDI customer data on the local instance of the macro on the user system through the macro on the user terminal; generating EDI customer data through the macro ; And EDI customer data is sent to the EDI system as an analysis result via a macro. In another embodiment, it provides a physical server for analyzing non-EDI customer data using an physical EDI system. The server includes: a processor; and a memory for storing executable by the processor Instructions. The processor is configured to execute: receive a login request from a user terminal; open a macro provided by the server; create a local instance of the macro on the user terminal through the macro; use the macro to log the client based on the client profile login ID The file instance is loaded from the archive to the local instance of the macro on the user terminal; and after the user terminal generates EDI customer data based on the non-EDI customer data, the macro receives EDI customer data from the user terminal as the analysis result. It should be understood that the above general description and the detailed description below are merely exemplary, and are not intended to limit the present invention.

In order that those with ordinary knowledge can thoroughly understand the present invention, detailed steps and structures will be proposed in the following description. Obviously, the implementation of the present invention is not limited to the specific details familiar to those skilled in the relevant art. On the other hand, well-known structures or steps are not described in detail to avoid unnecessary limitations of the present invention. The preferred embodiments of the present invention will be described in detail as follows. However, in addition to these detailed descriptions, the present invention can be widely implemented in other embodiments, and the scope of the present invention is not limited. The scope of the subsequent patent applications shall prevail . Exemplary embodiments will be described in detail herein, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments set forth in the following description of the exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of devices and methods consistent with aspects of the invention as detailed in the scope of the appended patent application. The present invention provides a system and method for integrating inbound information into an EDI system without passing through the EDI system (Electronic Data Interchange System) or making the information suitable for analysis. For example, Taiwan Patent Application No. 091108929, with a filing date of April 30, 2002, discloses an order processing method that automatically receives customer order data and confirms the order data based on the production schedule, which generally includes the following steps: Receive the EDI forecast order, convert the format of the EDI forecast order, generate the forecast order data, and store the forecast order data in the database; access the database to obtain the forecast order data and confirm the forecast order; forecast the order Carry out production scheduling, generate production schedule information, and store production schedule information in the database; perform format conversion to generate formal order data, and store formal order data in the database; etc. In addition, U.S. Patent No. 7,984,373B2 discloses a method for creating an EDI transaction based on the description of the EDI mode, which specifically includes receiving a description of the EDI mode and other documents specifying the format of the EDI mode. The description is a non-EDI structured document; separating the non-EDI structured document from other EDI documents; identifying multiple data units included in the separated non-EDI structured document; classifying the identified multiple data units as Data type; analyzing the classified multiple data units to determine the content of the EDI model; generating a document definition of the EDI model; and using the generated document definition to create an EDI transaction based on the EDI model. The EDI system in the prior art can only process EDI files. For this disclosure, data / information that is not from an EDI file can also be integrated into an EDI system. Generally speaking, EDI data refers to data that is exchanged and automatically processed between electronic computer systems via a communication network in accordance with the agreed-upon universal message standard format (such as X12 EDI, EDIFACT, etc.). For example, the EDI data may be data such as PDF, X12, TXT, XML, CSV, etc., but the present invention is not necessarily limited to this. Non-EDI data refers to data exchanged between electronic computer systems that are not transmitted via a communication network in accordance with the agreed universal message standard format. For example, the non-EDI data may be data from a mail or Excel, but the present invention is not necessarily limited to this. Taking the data / information about the order as an example, the present invention can integrate the non-EDI file order into the EDI system. In other words, non-EDI orders can be changed to EDI orders, which can then be entered into the EDI system. For brevity, the system for processing orders in the present invention is referred to as an order automation server application (referred to as OAS). However, the present invention is not limited to processing data / information about an order and then integrating them into an EDI system, and the present invention can be applied to any other case where data / information is processed and then integrated into an EDI system. According to an example, orders are mainly divided into two categories-scattered orders and total orders. OAS consists of multiple applications that semi-automate multiple order types throughout the life cycle of a sales order. Multiple applications include: order creation, order reordering, order confirmation, forecast analysis, forecast settlement, forecast recast, and forecast confirmation. According to an example, in order to implement the above application, OAS includes the following applications as part of it: 010_CSV ORDERS to IDOC Macro, used to create orders; 020_PO Update and CFM Macro, used to change (remake) and confirm orders; 030_SA Macro, It is used for predictive analysis, forecast settlement, forecast reproduction and forecast confirmation. CSR is a direct user of OAS applications that process customer orders / forecasts. The results of OAS predictive analysis are shared with fulfillment SE (three-dimensional computer-aided design software) to understand / estimate & meet customer business needs. OAS applications align the various non-EDI / e-based worksheet requirements from customers and integrate them into a single tool, and can tolerate customers' reluctance to switch to the EDI platform, so OAS applications use their original (Excel-based Infrastructure) to improve business continuity. Each time a change is required, the customer / CSR can make changes in the mapping, thereby minimizing dependence on the EDI / R & D department / IT team. Because data-driven decision making is a business need today, OAS applications are also a response to the lack of EDI when it comes to business analysis / statistical analysis. In one example, the OAS application has one or more of the following features, which can be modified by those skilled in the art based on actual needs. Since the user / CSR can only see the macro, it is a single access point to the server. Form the code in a way that only allows server applications to interact with it. This serves as an additional layer of security. It is easy for users to upgrade and understand. Macro is also backward compatible. This tool, the OAS application, is widely compatible with all businesses licensed by Microsoft Excel. This tool can generate data for EDI entry. Because the tool uses user system resources rather than server resources, the tool is very fast, lightweight, and resource-friendly. The tool is designed to run in read-only mode, but still enables multiple users to work on it simultaneously. Because the user / analyst maintains the complex logic in the macro set directly, the reference / mapping feature in some OAS applications allows the EDI team to only maintain a general map of the degree of sales (SoldTo). In one example, the reference / mapping feature accommodates 12 operators (such as include, equal, start, end, etc.) and up to 3 conditions, which can be any field in the customer profile and an entity profile (such as Molex (莫Shi) information) match. This gives users, such as CSR, endless possibilities to create relationship diagrams. A profile bank on the server is used as a knowledge base containing information about customer needs. This removes dependencies on any particular customer profile processed by the CSR. Instead of multiple EDI diagrams for each customer requirement, all requirements can be handled with a single application and an archive maintained directly by the user. This saves a lot of time and money, otherwise it would require investment in the EDI / IT R & D department. Referring to FIG. 4A, FIG. 4A illustrates a block diagram of an overall structure of an OAS according to an exemplary embodiment, which is basically a combination of FIG. 4B to FIG. 4D, and FIG. 4B to FIG. to IDOC Macro) and 020_PO Update and CFM Macro, and 030_SA Macro (030_SA Macro). The above three macros are placed on a server, according to an example, they are placed on a file server, and the above three macros can be accessed. Using the above macro, the supplier's EDI system can integrate non-EDI orders in response to customers sending non-EDI orders via email or other means rather than through the supplier's EDI system. In one embodiment, the OAS handles situations when a customer sends a non-EDI order directly to the supplier's CSR's private mailbox, or only provides the order orally or changes an existing order. As a naming convention, the customer items that are usually sold are used as the login name (LoginId) created by the archive or output file. In the case where a customer object to be sold requires multiple customer files, the login name can use [SoldTo] -1, [SoldTo] -2, [SoldTo] -3, etc. The files are stored in an OAS archive which can be located on the file server and can be accessed under names such as CSR_Order_Automation_profiles. The customer file stores all customer-sensitive information and logic / mappings in the form of a spreadsheet on the archive. The main purpose of creating a profile for each customer is to load different configurations / maps into the same application for different customers. Archives are usually hidden from the user, but have R / W (read / write) privileges and can be modified by load / save only through the application. The structure of the file is the same as that of the macro spreadsheet. Save archive is to save the currently active worksheet as an archive directory. Loading a file is to copy all the data for each configuration ("Init" screen) and other tables from the file to a worksheet for the current activity of that particular customer. The file name can be <MacroName> _ <LoginId> .xlsm. Three macros are described in detail below. Referring to FIG. 4B, the 010_CSV order to IDOC macro is used for non-EDI purchase order creation / determination order creation / automation. Referring to Figure 5A and Figure 5B, the 010_CSV order to IDOC macro provides the following tabs / screens for the CSR user terminal: Instruction tabs / screens This screen contains instructions for using the tool. CSR can simply follow the instructions and use the non-EDI data provided by the customer to obtain new orders to be placed in SAP. Initial Label / Screen This screen contains the parameters needed to map user-supplied data to the vendor's data format (for example, known as Molex Common Data). As an example, Molex common data can be in comma separated value (CSV) format. Field values in that screen are stored in rows B, G, and H of the screen. Fields generally store two types of values: Default value (DVAL)-This is the value used in the "CSV ORDER to IDO" screen when the customer has not provided information. First Reference-This field points to the first cell of the row in the customer data. For example, if the value of "Contacts-First Reference" is D2 in the "Initial" screen, it means that the customer has entered Row D in the contact profile from Row 2 in the "New PO" screen . If FREF is mentioned, it has priority over DVAL. Note: 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, place of delivery, order type, and batch-have multiple values, the corresponding fields should remain blank and Relationship diagrams must be defined in the Reference screen. As an example, the user has the option to provide three conditions to match each record from the customer profile to its corresponding record in the Molex universal profile. Reference Label / Screen This screen can be used when the same customer uses multiple ordering departments, delivery locations, payers, sales organizations, buyers, order types, and batches. This creates a relationship diagram to translate each record from the customer into its corresponding Molex universal profile. This general data is the input of the general graph "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 tags / screens Information received from customers must be placed here by CSR. CSV Order to IDOC (CSV ORDERS to IDOC) tab / screen 010_CSV Order to IDOC macro uses data from the new PO, the initial form, and the reference form to generate the screen. The data generated on this screen is saved as a CSV file in the output folder and then sent to SI by email to create an order in the system. Once all mandatory information is automatically filled using the existing file / entered by CSR for the first time, click on the button "Preparing CVS Order to Create a New PO in SAP" and translate the customer-specific information on the "New PO" screen Molex Generic Materials on the "CVS Order to IDOC" screen. Referring to Figures 5A and 5B, once the information on the "CVS Order to IDOC" screen is ready to be sent to Sterling Integrator (SI), the CSR selects the value "System Update" and then clicks the button "Send CSV order file as email" to send Data to SI of EDI system. 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 invention. The user terminal may be a smart device with a universal serial bus (USB), such as a smart phone, a notebook computer, a personal digital assistant (PDA), and the like. The user terminal creates a new EDI purchase order (PO) in the EDI system by integrating non-EDI customer data (non-EDI purchase order data) into an entity (such as a supplier) EDI system. The user terminal includes: a processor A display; and a memory for storing instructions executable by a processor; wherein the processor is configured to execute a method, the method includes: step 101: logging in to a server; step 103: opening a macro provided by the server (Order Creation Macro); Step 105: Create a local instance of the macro on the user terminal through the macro; Step 107: Receive the customer profile data through the macro; Step 109: On the user terminal On the local instance of the macro, the relationship between the format of the non-EDI customer data and the format of the non-EDI customer data and the format of the EDI customer data is obtained through the macro. The EDI customer data is the first EDI component (SI) of the EDI system. Use (According to an example, the format of the EDI customer profile is CSV format, which is "Molex Common Profile"); Step 111: Macro-based relationship diagram and non-EDI client The customer data generates EDI customer data; Step 113: Send the EDI customer data to the server, and the server integrates the EDI customer data into the first EDI component (SI) of the EDI system. The entity is a supplier, the non-EDI customer information is a non-EDI order from the mail or Excel, and the EDI customer information is in CSV format. The step 113 of sending the EDI customer data to the server includes: saving the CSV order to the server via a macro, and the server sending the CSV order via mail to the first EDI element (SI) of the EDI system. According to an example, the local instance of the macro is provided with a user interface; the relationship between the format of obtaining the non-EDI customer data and non-EDI customer data through the macro and the format of the EDI customer data used by the first EDI component is step 109. Including: Step 109-1: Receive input from the user via the INIT screen displayed on the user interface to create a relationship diagram; Step 109-3: Receive non-users from the user via the new PO screen displayed on the user interface The input of EDI customer data; and the step 111 of generating EDI customer data based on the relationship diagram and non-EDI customer data by the macro includes: Step 111-1: via the CVS order displayed on the user interface to the IDOC screen, based on the relationship graph and Generate CSV orders from non-EDI customer profiles. According to another example, a local instance of the macro is provided with a user interface, and the relationship between the format of the non-EDI customer data and non-EDI customer data and the format of the EDI customer data used by the first EDI component is obtained through the macro. 109 includes: Step 109-1 ': Receive user input via an INIT screen displayed on the user interface to create a first relationship diagram between the format of non-EDI customer data and the format of EDI customer data; Step 109- 2 ': If the mandatory field of the INIT screen has more than one value, the user's input is received via the reference screen displayed on the user interface to create a format between the format of the non-EDI customer data and the format of the EDI customer data Step 109-3 ': Receive non-EDI customer data entered by the user via a new PO screen displayed on the user interface; and use macros based on the relationship between non-EDI customer data and EDI customer data Step 111 of generating the EDI customer data by the relationship diagram includes: Step 111-1 ': via the CVS order displayed on the user interface to the IDOC screen, based on the first and second relationship diagrams and non-EDI customers Account details to generate CSV orders. According to another example, the step 107 of receiving the customer profile data through the macro includes: Step 107-1: receiving a user's selection of the option of using the existing customer profile for setting and manual setting; Step 107-2: Whether to A ready-made customer file is found in the database; step 107-3: if it is, then load data from the file library to the local instance of the macro on the user terminal based on the customer file login ID; and step 107-5: if not, A local instance of the macro entered by the user on the user terminal is received. FIG. 7 is a flowchart illustrating steps performed by a server in order to create a new purchase order (PO) according to an exemplary embodiment of the present invention. The server creates a new EDI purchase order (PO) in the EDI system by integrating non-EDI customer data (non-EDI purchase order data) into an entity (such as a supplier) EDI system. The server includes: a processor; a display And a memory for storing instructions executable by a processor; wherein the processor is configured to execute a method, the method includes: Step S201: receiving a login request from a user terminal; Step S203: opening a server provided by the server Macro (order creation macro); Step S205: Use the macro to create a local instance of the macro on the user terminal; Step S207: Use the macro to load the customer profile data from the archive to the database based on the customer profile login ID Local instance of the macro on the user terminal; Step S209: After the user terminal generates EDI customer data based on the non-EDI customer data, receive the EDI customer data of the user terminal through the macro; Step S211: integrate the EDI customer data Into the first EDI element (SI) of the EDI system. Referring to FIG. 4C, the 020_PO update and the CFM macro are used for the non-EDI purchase order / reorder / confirmation of the confirmation order. The 020_PO update and CFM macro provide the following screen for the CSR user terminal: Init Tab / Screen This screen contains the parameters needed to map customer-provided data and Molex SAP system data. Field values are stored in rows B, G, and H on the screen. Note: The value can be mandatory (red) or optional (black). The screen is divided into four sections: Control Reference: This section contains the main parameters that enable the application to understand the user's output needs. According to an example, the fields found under this section are: Use SO # to update VA02? (Yes / No)-If yes, SAP updates use SO #, otherwise use PO # and SoldTO. Block Order-CSR can be selected to apply or remove delivery blocking for all rows that it wants to update in SAP. Customer Open Open Order Reference: This section contains column instructions / references to the customer's open order data. For example, if the user has provided PO # in the "A" column, the field will include "A2" which is the first PO value in the customer profile. Molex Open Order References: This section contains column instructions / references to Molex open orders. For example, if the Molex SAP profile extract has PO # in the "A" column, the field will contain "A2" which is the first PO value in the Molex profile. Previous customer opened open order reference: This section contains column instructions / references to the customer's open order data for the previous week. For example, if the user has provided PO # in the "A" column, the field will include "A2" which is the first PO value in the customer profile. Molex opens the Incomplete Orders tab / screen The actual data presented for the customer in Molex SAP is extracted by the CSR. The customer opens the outstanding order label / screen. The information received from the customer must be placed here by the CSR. Previous customer opened the incomplete order tab / screen The information received from the customer last week must be placed here by CSR. The label / screen is optional. VA02 tag / screen This can be the output of a macro but is not required. Once the "Execute" button is clicked, the data generated on this screen is updated to SAP. Proceed as follows. Load the customer file. Load the file in the same way as all other macros. The CSR copies existing data from the last week on the "Customer Opens Outstanding Orders" screen to the "Previous Customer Opens Outstanding Orders" screen, but it is not required. CSR logs non-EDI customer data to the "Customer Opens Outstanding Order" screen. CSR pulls existing data for customers from SAP into the "Molex Open Outstanding Order" screen. Referring to Figure 8A, the CSR enters all required information about all parts of the "Initial" screen-the customer opens the open order reference, the control reference, the Molex open order reference, and the previous customer opens the open order reference (in the presentation and in the PO If there is a business need for analysis in the validation). Once all the above steps have been completed, the CSR clicks the "PO Change Macro" on the initial screen and / or then clicks the "PO Confirm Macro" button. This initiates a PO change and / or subsequent PO confirmation execution. According to a further example, a pivot table is generated. Complete all analyses and update tags in the customer's Open Pending Orders screen. After analyzing and updating the tags, these arrows in customer open open orders that match their respective Molex records and meet the criteria selected in the initial screen are moved to VA02 for update in SAP. Referring to FIG. 8B, once the CSR clicks the execute button on the VA02 screen, if an existing SAP session is open, a script to update the purchase order / sales order in SAP is executed. The application gives an error if there is no corresponding SAP session opened. After updating SAP on all table rows in the VA02 screen, control returns to the application with a success / check message. 9A-9C are flowcharts illustrating steps performed by a user terminal of a CSR for order change (reproduction) and confirmation according to an exemplary embodiment of the present invention. The user terminal may be a smart device with 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 an entity's EDI system. The user terminal can implement the order creation above and the order change (reproduction) 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 execute a method, the method includes: Step 301: Log in to a server; Step 303: Open the macro provided by the server (order change and confirmation macro); Step 305: Create a local instance of the macro on the user terminal through the macro; Step 307: Use the macro to upload the customer profile data based on the customer profile login ID The local instance of the macro loaded on the user terminal from the archive; Step 309: On the local instance of the macro on the user terminal, use the macro to obtain the format and format of the non-EDI customer data and non-EDI customer data. The relationship diagram between the formats of the EDI customer data used by the second EDI component (SAP) of the EDI system; Step 311: Using a macro to generate EDI customer data based on the relationship graph and non-EDI customer data; Step 313: Using a macro , Directly update EDI customer data to the second EDI component (SAP) of the EDI system. Step 313 of directly updating the EDI customer data through the macro includes: Step 313-1: Open the session with the second EDI component of the EDI system connected to the supplier's own internal information system (SAP session) through the macro. Step 313-2: Change or confirm the EDI customer data directly to the second EDI component (SAP) of the EDI system through the macro. The step 309 of obtaining the relationship diagram between the format of the non-EDI customer data and the non-EDI customer data through the macro and the format of the EDI customer data used by the second EDI component includes: Step 309-1: Via the display on the user interface The INIT screen receives user input to create a relationship diagram. Step 309-3: Receive an existing EDI order from the second EDI component (SAP) via the open outstanding order screen (Molex opens open order) displayed on the user interface. Step 309-5: Receive non-EDI customer data via the customer ’s open outstanding order screen displayed on the user interface; and step 311 of generating EDI customer data based on the relationship diagram and non-EDI customer data via macros includes: : Step 311-1: Use the PO change macro or PO confirmation macro on the INIT screen to respond to the change or confirmation of EDI customer data. 10A-10B are flowcharts illustrating steps performed by a server for order change (reproduction) and confirmation according to an exemplary embodiment of the present invention. The server can implement the order creation above and the order change (reproduction) 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 execute a method, the method includes: Step 401: receiving a login request from a user terminal; Step 403: Open the macro provided by the server (order change and confirmation macro); Step 405: Use the macro to create a local instance of the macro on the user terminal; Step 407: Use the macro to log in to the ID based on the customer profile Load the customer profile data from the archive into the local instance of the macro on the user terminal; Step 409: After the user terminal generates EDI customer data based on the non-EDI customer data, receive the EDI from the user terminal through the macro. Customer data; Step 411: Directly update the EDI customer data into the second EDI component of the EDI system through the macro. The steps of directly updating the EDI customer data through the macro include: Step 411-1: Open the session with the second EDI component of the EDI system connected to the supplier's own internal information system (SAP session) through the macro; and Step 411 -3: Directly change or confirm EDI customer data to the second EDI component of the EDI system through the macro. Referring to FIG. 4D, the 030_SA macro (forecast) is used to automate the commitment of predictive analysis, settlement, management, and non-EDI batch SA orders. It analyzes, tracks customer trends, proposes a number of plans, and finally uploads the data to SAP. 11A-11B are flowcharts illustrating steps performed by a user terminal in order to predict an order according to an exemplary embodiment of the present invention. The user terminal can implement the above order creation, order change (reproduction) and confirmation, and the forecast 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 execute a method, the method includes: step 501: logging in to a server; step 503: Open the macro provided by the server (SA macro); Step 505: Create a local instance of the macro on the user terminal through the macro; Step 507: Load the customer profile data from the archive database based on the client profile login ID through the macro The local instance of the macro on the user terminal is entered; Step 509: On the local instance of the macro on the user system, the input of non-EDI customer data is received through the macro on the user terminal; Step 511: Via the macro Set to generate EDI customer data; Step 513: send the EDI customer data to the EDI system as an analysis result through a macro. Step 513 of sending the EDI customer data to the EDI system as an analysis result through the macro includes at least one of the following steps: Step 513-1: Saving the EDI customer data to the server through the macro; and Step 511-3: Passing The macro sends EDI customer data directly to the second EDI component (SAP) of the EDI system. FIG. 12 is a flowchart illustrating steps performed by a server in order to predict an order according to an exemplary embodiment of the present invention. The server can implement the order creation, order change (reproduction) and confirmation above, and the forecast 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 execute a method, the method includes: Step 601: receiving a login request from a user terminal; Step 603: Open the macro provided by the server (SA macro); Step 605: Use the macro to create a local instance of the macro on the user terminal; Step 607: Use the macro to log in to the client based on the client's file login ID. The client file data is loaded from the archive to the local instance of the macro on the user terminal. Step 609: After the user terminal generates EDI customer data based on the non-EDI customer data, the macro receives the EDI client from the user terminal. data. Referring to FIG. 13, the device 1300 may be a user terminal including one or more of the following elements: a processing element 1302, a memory 1304, a power element 1306, a multimedia element 1308, an audio element 1310, and an input / output (I / O) interface 1312. , A sensor element 1314, and a communication element 1316. The processing element 1302 generally controls overall operations of the device 1300, such as operations associated with display, telephone calls, data communications, camera operations, and recording operations. The processing element 1302 may include one or more processors 1320 to execute instructions to complete all or part of the steps of the method described above. In addition, the processing element 1302 may include one or more modules to facilitate interaction between the processing element 1302 and other elements. For example, the processing element 1302 may include a multimedia module to facilitate the interaction between the multimedia element 1308 and the processing element 1302. The memory 1304 is configured to store various types of data to support operations on the device 1300. Examples of such materials include instructions for any application or method operating on the device 1300, contact information, phonebook information, messages, pictures, videos, and the like. The memory 1304 may be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable and programmable read-only memory (EEPROM), Erasable and Programmable Read Only Memory (EPROM), Programmable Read Only Memory (PROM), Read Only Memory (ROM), magnetic memory, flash memory, magnetic disk or optical disc. The power supply element 1306 provides power to various elements of the device 1300. The power supply element 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 device 1300. The multimedia component 1308 includes a screen that provides 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, swipe, and gestures on the touch panel. The touch sensor may not only sense a boundary of a touch or sliding action, but also detect duration and pressure related to the touch or sliding operation. In some embodiments, the multimedia element 1308 includes a front camera and / or a rear camera. When the device 1300 is in an operation mode, such as a shooting mode or a video mode, the front camera and / or the rear camera can receive external multimedia data. Each front camera and rear camera can be a fixed optical lens system or have focal length and optical zoom capabilities. The audio element 1310 is configured to output and / or input an audio signal. For example, the audio element 1310 includes a microphone (MIC). When the device 1300 is in an operation mode, such as a call mode, a recording mode, and a voice recognition mode, the microphone is configured to receive an external audio signal. The received audio signals may be further stored in the memory 1304 or transmitted via the communication component 1316. In some embodiments, the audio element 1310 further includes a speaker for outputting an audio signal. The I / O interface 1312 provides an interface between the processing element 1302 and a peripheral interface module. The peripheral interface module may be a keyboard, a click wheel, a button, or the like. These buttons may include, but are not limited to: a home button, a volume button, a start button, and a lock button. The sensor element 1314 includes one or more sensors for providing status assessment of various aspects of the device 1300. For example, the sensor element 1314 may detect the on / off state of the device 1300, the relative positioning of the components of the device 1300 (such as a display and a keypad), the change in the position of the device 1300 or the components of the device 1300, the contact of the user with the device 1300 Presence or absence, orientation or acceleration / deceleration of the device 1300, and changes in temperature of the device 1300. The sensor element 1314 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. The sensor element 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 element 1314 may further include an acceleration sensor, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor. The communication element 1316 is configured to facilitate wired or wireless communication between the device 1300 and other devices. The device 1300 can access a wireless network based on a communication standard, such as WiFi, 2G, 3G, or 4G cellular technology, or a combination thereof. In an exemplary embodiment, the communication element 1316 receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 1316 further includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module can 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 device 1300 may use one or more application specific integrated circuit (ASIC), digital signal processor (DSP), digital signal processing device (DSPD), programmable logic device (PLD), field Programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components are implemented to perform the above methods. In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions, such as a memory 1304 including instructions, may be executed by the processor 1320 of the device 1300 to complete the foregoing method. 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 exemplary embodiment of the present invention. For example, the device 1400 may be a server. Referring to FIG. 14, the device 1400 includes a processing element 1422, which further includes one or more processors and storage resources represented by the memory 1432 for storing instructions executable by the processing element 1422, such as applications. The application program stored in the memory 1432 may include one or more modules, and each module corresponds to a set of instructions. Moreover, the processing element 1422 is configured to execute instructions to perform the above method for integrating non-EDI customer data into the EDI system and / or analyzing non-EDI customer data with the EDI system. The device 1400 may further include a power supply element 1426 configured to perform power management of 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 1458. The device 1400 can be operated based on an operating system stored in a memory, such as Windows ServerTM, Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM, and the like. It should be understood that the present invention is not limited to the precise structure that has been described above and shown in the drawings, and various modifications and changes can be made without departing from the scope thereof. The scope of the present invention is limited only by the scope of the attached patent applications. The technical content and technical features of this disclosure have been disclosed as above. However, those with ordinary knowledge in the technical field to which this disclosure belongs should understand that without departing from the spirit and scope of this disclosure as defined by the appended patent scope, the teachings and disclosure of this disclosure Can be used for various substitutions and modifications. For example, many of the processes disclosed above can be implemented in different ways or replaced with other processes, or a combination of the two methods described above. In addition, the scope of rights in this case is not limited to the process, machine, manufacture, material composition, device, method or step of the specific embodiments disclosed above. Those with ordinary knowledge in the technical field to which this disclosure belongs should understand that based on the teaching and disclosure of this disclosure and revealing the process, machine, manufacturing, material components, devices, methods or steps, whether it exists now or in the future, its developers and embodiments The revealer performs substantially the same function in substantially the same way, and achieves substantially the same result, which can also be used in this disclosure. Therefore, the scope of patent application below covers such processes, machines, manufacturing, material ingredients, devices, methods or steps.

101, 103, 105, 107, 109, 111, 113, 109-1, 109-3, 111-1, 109-1 ', 109-2', 109-3 ', 111-1', 107-1, 107-2, 107-3, 107-5, 201, 203, 205, 207, 209, 211, 301, 303, 305, 307, 309, 311, 313, 313-1, 313-2, 309-1, 309-3, 309-5, 311-1, 401, 403, 405, 407, 409, 411, 411-1, 411-3, 501, 503, 505, 507, 509, 511, 513, 513-1, 513-3, 601, 603, 605, 607, 609‧‧‧ steps

1302, 1422‧‧‧ processing elements

1304, 1432‧‧‧Memory

1306, 1426‧‧‧ Power components

1308‧‧‧Multimedia components

1310‧‧‧Audio components

1312, 1458‧‧‧ Input / Output (I / O) interface

1314‧‧‧Sensor element

1316‧‧‧Communication components

1320‧‧‧Processor

1450‧‧‧Interface 1450

The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate embodiments consistent with the invention, and together with the description serve to explain the principles of the invention. FIG. 1 is an example of a conventional EDI architecture between two trading companies of the present invention. FIG. 2 is an example of an intranet of a company having an EDI system according to the present invention. FIG. 3 is an example of how the present invention translates and converts EDI files in different formats for inbound and outbound processes in a company's intranet. FIG. 4A is an example of an overall structural block diagram of an OAS according to an exemplary embodiment of the present invention. FIG. 4B is an example of a block diagram of an overall structure of an OAS designed to create a new purchase order (PO) in the SAP of the EDI system according to an exemplary embodiment of the present invention. FIG. 4C is an example of an overall structure block diagram of an OAS designed for order change (reproduction) and confirmation in the SAP of the EDI system according to the exemplary embodiment of the present invention. FIG. 4D is an example of a block diagram of an overall structure of an OAS designed to make predictions according to an embodiment of the present invention. 5A-5B are examples of a user interface of an OAS designed to create a new purchase order (PO) according to an embodiment of the present invention. 6A-6D are flowcharts of steps performed by a user terminal in order to create a new purchase order (PO) according to an embodiment of the present invention. 7 is a flowchart of steps performed by a server in order to create a new purchase order (PO) according to an embodiment of the present invention. 8A-8B are examples of a user interface of OAS designed for order change (reproduction) and confirmation according to an embodiment of the present invention. 9A-9C are flowcharts of steps performed by a user terminal for order change (reproduction) and confirmation according to an embodiment of the present invention. 10A-10B are flowcharts of steps performed by a server for order change (reproduction) and confirmation according to an embodiment of the present invention. 11A-11B are flowcharts of steps performed by a user terminal for prediction according to an embodiment of the present invention. FIG. 12 is a flowchart of steps performed by a server for prediction according to an embodiment of the present invention. 13 is a block diagram of a device for integrating non-EDI customer data into an EDI system or analyzing non-EDI customer data using an EDI system according to an embodiment of the present invention. FIG. 14 is a block diagram of a device for integrating non-EDI customer data into an EDI system and / or analyzing non-EDI customer data using an EDI system according to an embodiment of the present invention.

Claims (20)

A user terminal for integrating non-EDI customer data into a physical EDI system, the user terminal includes: a processor; a display; and a memory for storing instructions executable by the processor; wherein The processor is configured to execute: log in to the server; open a macro provided by the server; create a local instance of the macro on the user terminal through the macro; receive a client file through the macro On the local instance of the macro on the user terminal, the format of the non-EDI customer data and non-EDI customer data and the first EDI (electronic Data exchange) relationship diagram between formats of EDI customer data used by the component; generating EDI customer data based on the relationship graph and the non-EDI customer data through a macro; and sending the EDI customer data to the server The server integrates the EDI customer data into the first EDI component of the EDI system. The user terminal according to claim 1, wherein 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 (comma separated value format) order . The user terminal according to claim 2, wherein sending the EDI customer data to the server comprises: saving the CSV order to the server via the macro, and the server via email Sending the CSV order to the first EDI element of the EDI system. The user terminal according to claim 3, wherein the local instance of the macro is provided with a user interface; obtaining non-EDI client data and the format of the non-EDI client data through the macro and the The relationship diagram between the formats of the EDI customer data used by the first EDI component includes: receiving an input from a user via an INIT screen displayed on the user interface to create the relationship diagram; The new PO (purchase order) screen displayed on the interface receives the non-EDI customer data entered by the user; and generating the EDI customer data based on the relationship diagram and the non-EDI customer data through the macro includes: The CVS order displayed on the user interface is sent to the IDOC screen, and the CSV order is generated based on the relationship diagram and the non-EDI customer data. The user terminal according to claim 3, wherein the local instance of the macro is provided with a user interface; obtaining the non-EDI client data and the format of the non-EDI client data through the macro and the first The relationship between the formats of the EDI customer data used by the EDI component includes: receiving input from a user via an INIT screen displayed on the user interface to create the format of the non-EDI customer data and the EDI customer data A first relationship diagram between formats; if a mandatory field of the INIT screen has more than one value, receiving a user ’s input via a reference screen displayed on the user interface to create A second relationship diagram between the format of the non-EDI customer data and the format of the EDI customer data; receiving the non-EDI customer data input by the user via a new PO screen displayed on the user interface; and The macro generating the EDI customer data based on the relationship diagram between the non-EDI customer data and the EDI customer data includes: passing a CVS order displayed on the user interface to an IDOC ( Between documents) screen, generate the CSV order based on the first map and the second map and the non-EDI customer data. The user terminal according to claim 1, wherein the receiving of the customer profile data through the macro includes: receiving a user's selection of an option to use an existing customer profile for setting and manual setting; if found in the archive Ready-made customer files, based on the customer file login ID (account number), load data from the file library to the local instance of the macro on the user terminal; and if no ready-made files are found in the file library The client file receives the user's input to the local instance of the macro on the user terminal. A server for integrating non-EDI client data into a physical EDI system, the server includes: a processor; and a memory for storing instructions executable by the processor; wherein the processor is configured to Executing: receiving a login request from a user terminal; opening a macro provided by the server; using the macro to create a local instance of the macro on the user terminal; using the macro, based on Customer profile login ID loads customer profile data from the archive to the local instance of the macro on the user terminal; after the user terminal generates EDI customer profile based on non-EDI customer profile, The macro receives the EDI customer data of the user terminal; and integrates the EDI customer data into a first EDI component of an EDI system. The server according to claim 7, wherein 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. The server according to claim 8, wherein integrating the EDI customer data into an EDI system includes: sending the CSV order to a first EDI component of the EDI system by mail. A user terminal for integrating non-EDI customer data into a physical EDI system, the user terminal includes: a processor; a display; and a memory for storing instructions executable by the processor; wherein The processor is configured to execute: log in to the server; open the macro provided by the server; use the macro to create a local instance of the macro on the user terminal; based on the macro, based on Customer profile login ID loads customer profile data from the archive into the local instance of the macro on the user terminal; through the macro, the macro on the user terminal On the local instance, obtaining a relationship diagram between a format of non-EDI customer data and non-EDI customer data and a format of EDI customer data used by a second EDI component of an EDI system; and based on the relationship through the macro, Map and the non-EDI customer data to generate EDI customer data; and directly update the EDI customer data into the second EDI component of the EDI system through the macro. The user terminal according to claim 10, wherein the entity is a supplier; and directly updating the EDI customer data through the macro comprises: opening the connection with the EDI system through the macro. A session of a second EDI component, the EDI system is connected to the supplier's own internal information system; and the EDI customer data is directly changed or confirmed to the second of the EDI system through the macro EDI components. The user terminal according to claim 11, wherein the local instance of the macro is provided with a user interface; the format of the non-EDI client data and the non-EDI client data obtained through the macro are The relationship diagram between the formats of the EDI customer data used by the second EDI component includes: receiving input from a user via an INIT screen displayed on the user interface to create the relationship diagram; The open outstanding order screen displayed on the user interface receives the EDI customer data of the existing EDI order from the second EDI component; the open outstanding order screen displayed on the user interface receives The non-EDI customer data; and generating the EDI customer data based on the relationship graph and the non-EDI customer data through the macro includes: via a PO change macro or a PO confirmation macro on the INIT screen to Corresponding to the change or confirmation of EDI customer data. A server for integrating non-EDI client data into a physical EDI system, the server includes: a processor; and a memory for storing instructions executable by the processor; wherein the processor is configured to Executing: receiving a login request from a user terminal; opening a macro provided by the server; using the macro to create a local instance of the macro on the user terminal; using the macro, based on Customer profile login ID to load customer profile data from the archive to the local instance of the macro on the user terminal; generating the EDI customer profile based on the non-EDI customer profile at the user terminal Then, receiving the EDI customer data from the user terminal through the macro; and directly updating the EDI customer data into the second EDI component of the EDI system through the macro. The server according to claim 13, wherein the entity is a supplier; and directly updating the EDI customer data through the macro comprises: opening the second EDI with the EDI system through the macro. Component session, the EDI system is connected to the supplier's own internal information system; and the EDI customer data is directly changed or confirmed to the second EDI component through the macro. A user terminal uses a physical EDI system to analyze non-EDI customer data. The user terminal includes: a processor; a display; and a memory for storing instructions executable by the processor; wherein the processor is configured to Executing: logging in to the server; opening a macro provided by the server; creating a local instance of the macro on the user terminal through the macro; and using the macro to register a client profile based on a client profile login ID Data is loaded from the archive into the local instance of the macro on the user terminal; through the macro on the user terminal, the macro of the macro on the user system On the local instance, receiving inputted non-EDI customer data; generating EDI customer data through the macro; and sending the EDI customer data to an EDI system as an analysis result through the macro. The user terminal according to claim 15, wherein 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. The user terminal according to claim 16, wherein sending the EDI customer data as an analysis result to the EDI system through the macro includes at least one of the following steps: using the macro to send the EDI customer data is stored in the server; and the EDI customer data is sent directly to the second EDI component of the EDI system through the macro. A server for analyzing non-EDI client data using an entity's EDI system. The server includes: a processor; and a memory for storing instructions executable by the processor; wherein the processor is configured to execute: Receive a login request from a user terminal; open a macro provided by the server; create a local instance of the macro on the user terminal through the macro; and use the macro to remove customer profile data from the file based on the client profile login ID The library loads the local instance of the macro on the user terminal; and after the user terminal generates EDI customer data based on non-EDI customer data, the macro is used to retrieve data from the user through the macro. The terminal receives the EDI customer data as the analysis result. The server according to claim 18, wherein the entity is a supplier, the non-EDI customer data is a non-EDI order from a mail or Excel, and the EDI customer data is in a CSV format. The server according to claim 19, wherein after receiving the EDI customer data from the user terminal as an analysis result through the macro, the method further includes at least one of the following steps: In the EDI customer profile sending email, the email will be sent by the user to the customer; through the macro, the non-EDI client profile is automatically extracted into the main fluctuation report in the common platform; and through the macro Receiving the EDI customer data to a first EDI component of the EDI system; and directly uploading the EDI customer data to a second EDI component of the EDI system through the macro.