CN108959202A - Handle the device of non-electronic data switched data - Google Patents

Abstract

This disclosure relates to the device for handling non-EDI data, including non-EDI customer data being integrated into the EDI system an of entity and utilizing the non-EDI customer data of EDI network analysis.The device loads customer profile, and for user provides user interface with the relational graph between the EDI data that input in non-EDI customer data and non-EDI data and EDI system, to generate the input of EDI data as EDI system.

Description

Devices for processing non-EDI data

technical field

The present disclosure relates generally to the exchange of data between disparate devices, and more particularly to a method for integrating information that does not come in via an EDI system (Electronic Data Interchange) into an EDI system and/or processing the information to make it suitable for analysis/ Means for statistical analysis.

Background technique

EDI (Electronic Data Interchange) is an electronic communication method providing a standard for exchanging data via any electronic means. By following the same standard, two different companies or organizations, even in two different countries, can electronically exchange documents (such as purchase orders, bills, shipping notes, and many other documents). There are many EDI standards (including X12EDI, EDIFACT, etc.), some of which address the needs of specific industries or regions. Standards are used to make EDI "Machine-Machine Interaction of Strictly Formatted Messages". EDI can then be formally defined as: the transfer of structured data from one computer system to another through agreed message standards without human intervention.

EDI can be transmitted using any method agreed upon by the sender and receiver. This includes a variety of 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, ie, delivery of EDI documents via e-mail. Trading partners can interact directly, or through an intermediary such as a Value Added Network (VAN).

EDI files often contain the same information that would normally be found in paper files used for the same organizational functions. For example, a manufacturer uses EDI 940 Warehouse-to-Ship Order to tell a retailer a product to warehouse-to-ship. Typically have a "Ship To" address, a "Bill To" address, and a list of product numbers (usually Universal Product Codes (UPCs)) and quantities. Another example is the arrangement of messages between sellers and buyers, such as Requests for Quotations (RFQs), Bids in Response to RFQs, Purchase Orders, Purchase Order Confirmations, Shipping Notes, Notices of Receipt, Billing and Payment Advice. However, EDI is not limited to only trade-related business data but encompasses all fields such as medicine (eg patient records and laboratory results), transportation (eg container and shipping information), engineering and construction, etc.

Referring to Fig. 1, Fig. 1 shows an example of a traditional EDI architecture, which is used to exchange EDI documents between two trading companies using EDI systems respectively, with a value-added network (VAN for short) between them. Each company's EDI system includes communication means for receiving EDI files, EDI conversion means for translating and converting the EDI files into a format that can be imported into the company's own internal information system.

For "outbound" documents, the EDI system will export the document (or read the database) from the company's internal information system or ERP (enterprise resource planning) and convert the document into a format suitable for the translator. A translator (usually translation software) will then "validate" the document to ensure it meets the standards agreed upon by the trading partner, convert the document into "EDI" format (adding appropriate identifiers and control structures) and translate the document using the appropriate communication protocol Send to trading partners, either indirectly via VAN or directly using protocols such as FTP or AS2.

For "inbound" files, the EDI system will receive the EDI file indirectly via VAN or directly using protocols such as FTP or AS2, obtain the received EDI file, verify that the trading partner sending the EDI file is a valid trading partner, and the structure of the EDI file meets The corresponding fields of the EDI standard and information conversion conform to the agreed protocol. Typically, the first step is to receive the EDI file from the mailbox through a translator, which will create a fixed-length or variable-length file or a format marked up in XML. The next step is to convert/convert the file, where 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 using a standard data transformation language such as XSLT, using custom programs, integrated proprietary "mappers", or integrated standards-based graphical "mappers". The final step is to import the converted files into the company's own internal information system.

For example, with reference to Figures 2 and the upper part of Figure 3, for the "inbound" process, the company's translator could be a product of IBM, the Sterling B2B Integrator (abbreviated as SI), which will transfer data from the EDI mail server/file server The received EDI format files, 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 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.

A 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 unwilling to switch to EDI platforms, so they still send non-EDI files, causing their partners to integrate information slowly and have a high chance of errors.

As an example, orders are common for trading partners such as suppliers and their customers. Orders include purchase orders, modification orders, and forecast orders, among others.

It is common that the client company has a legacy (Excel based) infrastructure and its employees are used to sending Excel orders to suppliers using EDI systems. The person responsible for the order at 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 devices such as mobile phones, many customers send orders to CSRs in suppliers by email, which results in slow integration of information and high error rates.

Furthermore, since 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 in the mail or record the contents of the phone call, and change the information and content. Also, 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 the information.

Whether the format of the non-EDI order is Excel, other spreadsheet programs, or mail, or even just from a telephone call, etc., there are various customer requirements that need to be entered into the supplier's own system, including the agreement between the customer and the supplier. Content/Layout/Format Terms and Conditions.

In addition, there is an increasing demand for business analysis/statistical analysis using various data. The data/information entered into the supplier's own system via the EDI system can be readily used for analysis/statistical analysis whereas the data/information not via the EDI system is not.

Contents of the invention

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

In one embodiment, a user terminal for integrating non-EDI customer data into an entity's EDI system is disclosed, the user terminal comprising: a processor; a display; and memory for storing instruction. The processor is configured to perform: logging into the server; opening a macro provided by the server; via the macro, creating a local instance of the macro on the user terminal; via the macro, receiving customer profile data; A macro to obtain non-EDI customer data and a relationship diagram between the format of the non-EDI customer data and the format of the EDI customer data used by the first EDI system component of the EDI system; through the macro, generate EDI based on the relationship diagram and the non-EDI customer data Customer data; sending the EDI customer data to the server, which integrates the EDI customer data into the first EDI component of said EDI system.

In another embodiment, a server for integrating non-EDI client data into an entity's EDI system is disclosed, the server comprising: a processor; and memory 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 the server; via the macro, creating a local instance of the macro on the user terminal; via the macro, receiving customer profile data; Profile Login ID loads customer profile data from a profile repository to said local instance of said macro on said user terminal; receives EDI from said user terminal after said user terminal generates EDI customer data based on non-EDI customer data customer data; and a first EDI component integrating said EDI customer data into an EDI system.

In another embodiment, a user terminal for integrating non-EDI client data into an entity's EDI system is disclosed, comprising: a processor; a display; and memory 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 the macro on the user terminal through the macro; loading customer profile data from the archive to the user terminal based on the customer profile login ID through the macro a local instance of the macro on the user terminal; obtaining non-EDI client data and the format of the non-EDI client data and the format of the EDI client data used by the second EDI component of the EDI system via the macro on the local instance of the macro at the user terminal relationship diagrams; generate EDI customer data based on the relationship diagram and non-EDI customer data through macros; and update non-EDI customer data directly to the second EDI component of the EDI system through macros.

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

In another embodiment, a user terminal for analyzing non-EDI customer data with an entity's EDI system is disclosed, comprising: a processor; a display; and memory storing instructions executable by the processor. The processor is configured to perform: logging into the server; opening a macro provided by the server; creating a local instance of the macro on the user terminal via the macro; loading customer profile data from the profile repository to the macro on the user terminal via the macro based on the customer profile login ID local instance; receiving input of non-EDI customer data on the local instance of the macro on the user system via said macro on the user terminal; generating EDI customer data via the macro; and sending the EDI customer data as analysis results to the EDI system via the macro .

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

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

Description of drawings

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

Figure 1 shows an example of a traditional EDI architecture between two trading companies.

Figure 2 shows an example of an internal network of a company with an EDI system.

Figure 3 shows an example of how EDI files of different formats are translated and converted for inbound and outbound processes in a company's internal network.

FIG. 4A is an example of an overall structural block diagram of an OAS according to an exemplary embodiment.

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

4C is an example of an overall structural block diagram of an OAS designed for order change (remake) and confirmation in 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, according to an exemplary embodiment.

5A-5B are examples of a user interface of an OAS designed for creating a new purchase order (PO), according to an exemplary embodiment.

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 in order to create a new purchase order (PO) according to an exemplary embodiment of the present disclosure.

8A-8B are examples of user interfaces of the OAS designed for order changes (remakes) and confirmations, according to an exemplary embodiment.

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

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

11A-11B are flowcharts illustrating steps performed by a user terminal for prediction, according to an exemplary 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.

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

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

Detailed ways

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, the same numerals in different drawings refer to the same or similar elements unless otherwise indicated. The implementations set forth in the following description of the exemplary embodiments do not represent all implementations consistent with the present disclosure. Rather, they are merely examples of apparatuses and methods consistent with aspects of the present disclosure as recited in the appended claims.

The present disclosure provides a system and method for integrating inbound information that does not go through an EDI system (Electronic Data Interchange) into an EDI system, or otherwise making the information suitable for analysis.

For example, Taiwan Patent Application No. 091108929 with an application date of April 30, 2002 discloses an order processing method that automatically receives customer order information and confirms the order information 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; obtain the forecast order data by accessing the database, and confirm the forecast order; The order performs production scheduling operations, generates production scheduling information, and stores the production scheduling information in the database; performs format conversion to generate formal order data, and stores the formal order data in the database; and so on.

In addition, U.S. Patent No. US 7,984,373B2 discloses a method for creating EDI transactions based on the description of the EDI schema, which specifically includes: receiving the description of the EDI schema and other documents in the format of the specified description of the EDI schema, receiving The description is a non-EDI structured document; separate a non-EDI structured document from other EDI documents; identify multiple data units included in the separated non-EDI structured document; classify the identified multiple data units is a data type; analyzing the classified plurality of data units to determine content of the EDI schema; generating a document definition of the EDI schema; and creating an EDI transaction from the EDI schema using the generated document definition.

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

Generally speaking, EDI data refers to the data exchanged and automatically processed between electronic computer systems via communication network transmission in accordance with the agreed general message standard format (eg, X12EDI, EDIFACT, etc.). For example, 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 that is not exchanged between electronic computer systems via communication network transmission in accordance with the agreed general message standard format. For example, non-EDI data could be data from mail or Excel, although the disclosure is not necessarily limited thereto.

Taking data/information about orders as an example, the present disclosure enables the integration of orders for non-EDI documents into an EDI system. In other words, non-EDI orders can be changed into EDI orders, which can then be entered into the EDI system. For the sake of brevity, the system for processing orders is referred to as an Order Automation Server Application (abbreviated as OAS) in this disclosure.

However, the present disclosure is not limited to processing data/information about orders and then integrating them into an EDI system, the present disclosure can be applied to any other situation 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 bulk orders. OAS is comprised of multiple applications that semi-automate various order types throughout the lifecycle of a sales order. Multiple applications include: create order, reorder, order confirmation, forecast analysis, forecast settlement, forecast remake, and forecast confirmation.

According to an example, in order to implement the above-mentioned applications, the OAS contains the following applications as part of it:

010_CSV ORDERS to IDOC Macro, used to create orders;

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

030_SA Macro for forecast analysis, forecast settlement, forecast remake and forecast confirmation.

CSR is a direct user of OAS application that handles customer's order/forecast, and the results of OAS predictive analysis are shared with Fulfillment SE (3D CAD software) to understand/estimate & meet customer's business needs.

OAS applications align various non-EDI/spreadsheet-based requirements from customers and integrate them into a single tool, and can accommodate customers' reluctance to switch to EDI platforms, so OAS applications use their original (Excel-based ) infrastructure to improve business continuity.

Clients/CSRs can make changes in the mapping every time a change is required, thereby minimizing reliance on EDI/R&D/IT teams.

Since data-driven decision-making is today's business need, OAS applications are also a response to the absence of EDI when it comes to business analysis/statistical analysis.

In an 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 (Macro), it is a single point of access to the server.

The code is formed in such a way that only the server application is allowed to interact with it. This acts as an extra layer of security.

It is easy to upgrade and understandable for users. Macros are also backward compatible.

This tool, the OAS application, is broadly compatible with all companies with a Microsoft Excel license.

This tool can generate data for EDI entry.

The tool is very fast, light weight and resource friendly as it uses the user's system resources instead of the server's.

The tool is designed to run in read-only mode, but still enable multiple users to work on it at the same time.

The reference/mapping feature in some OAS applications allows the EDI team to only maintain generic diagrams at the SoldTo level since the user/analyst directly maintains the complex logic in the macro.

In one example, the reference/mapping feature accommodates 12 operators (such as contains, equals, begins, ends, etc.) ) data) matches. This gives users, such as CSR, unlimited possibilities to create relationship diagrams.

The profile library (Profile Bank) on the server is used as a knowledge base containing customer demand information. This removes any dependency on specific customer data being handled by the CSR.

Instead of multiple EDI diagrams for each customer requirement, all requirements can be handled with a single application and archive maintained directly by the user. This saves a lot of time and money that would otherwise require investment in EDI/IT R&D.

Referring to FIG. 4A, FIG. 4A shows an overall structural block diagram of an OAS according to an exemplary embodiment, which is basically a combination of FIG. 4B to FIG. 4D. FIG. 4B to FIG. ) and 020_PO Update and CFM Macro (020_PO Update and CFM Macro), and 030_SA Macro (030_SAMacro).

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

Using the macros described above, the supplier's EDI system is able to consolidate non-EDI orders in response to a customer sending a non-EDI order by mail or other means rather than through the supplier's EDI system.

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

As a naming convention, usually the customer object to be sold is used as the login name (LoginId) for archive or output file creation. In the case that a customer object to be sold requires multiple customer files, the login name can use [SoldTo]-1, [SoldTo]-2, [SoldTo]-3 and so on.

Profiles are stored in an OAS archive that can be located on a file server and can be accessed with names such as CSR_Order_Automation_profiles. The customer profile stores all customer sensitive information and logic/mapping in spreadsheet form on the profile repository. The main purpose of creating archives for each customer is to load different configurations/maps into the same application for different customers. Archives are normally hidden from the user, but have R/W (read/write) privileges and can be modified by load/save only by the application. The structure of the file is the same as that of a macro spreadsheet. Save file is to save the currently active worksheet as a file directory. Loading a dossier copies each configuration ("Init" screen) and all data from the dossier's other tables to the currently active worksheet for that particular customer. The file name can be <MacroName>_<LoginId>.xlsm.

The three macros are described in detail below.

Referring to Figure 4B, the 010_CSV order to IDOC macro is used for non-EDI purchase order/firm order creation/automation.

5A and 5B, the 010_CSV order to IDOC macro provides the following tabs/screens for the user terminal of the CSR:

Command Tab/Screen

This screen contains instructions for using the tool. The CSR can simply follow the instructions and use the non-EDI data provided by the customer to get the new order to be placed in SAP.

Initial Tab/Screen

This screen contains the parameters needed to map the user-supplied data to the vendor's data format, known for example as Molex Generic Data. As an example, Molex general data may be in comma separated value (CSV) format. Field values in this screen are stored in columns B, G, and H of the screen. Fields typically 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 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 the contact data in column D from Row (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, Ordering Team, Delivery Place, Order Type and Batch has more than one value, the corresponding field should remain blank and the A diagram must be defined in the "References" screen. As an example, the user has the option to provide three criteria to match each record from the customer data to its corresponding record in the Molex general data.

Reference Tab/Screen

Use this screen when the same customer uses multiple order offices, ship-to, bill-to, sales organization, buyer, order types, and batches. This creates a relationship graph to translate each record from a customer into its corresponding Molex common data. This generic data is the input to the generic 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 Tab/Screen

Data received from clients must be placed here by the CSR.

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

The 010_CSV Order to IDOC macro generates this screen using data from the new PO, the original form, and the reference form. The data generated in this screen is saved as a CSV file in the output folder and is then emailed to the SI to create the order in the system.

Once all the mandatory information is auto-filled/entered by the CSR for the first time using the existing dossier, click on the button "Prepare CVS order to create a new PO in SAP" and place the customer-specific data in the "New PO" screen Translate to Molex Generic Data in the "CVS Order to IDOC" screen.

Referring to Figure 5A and Figure 5B, once the data on the "CVS Order to IDOC" screen is ready to be sent to the Sterling Integrator (SI), then the CSR selects the value "System Update" and clicks on the button "Send CSV Order File as Mail" to send Data to the SI of the 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 disclosure.

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. User terminals create new EDI purchase orders (PO) in the EDI system by integrating non-EDI customer data (non-EDI purchase order data) into the EDI system of an entity (such as a supplier), and user terminals include:

processor;

display; and

memory for storing instructions executable by the processor;

Wherein the processor is configured to perform a method comprising:

Step 101: log in to the server;

Step 103: Open the macro (Order Creation Macro) provided by the server;

Step 105: Create a local instance of the macro on the user terminal through the macro;

Step 107: receiving the data of the customer file through the macro;

Step 109: On the local instance of the macro on the user terminal, obtain the non-EDI customer data and the relationship diagram between the format of the non-EDI customer data and the format of the EDI customer data through the macro, and the EDI customer data is provided by the first EDI system. EDI component (SI) usage (according to one example, the format of EDI customer data is in CSV format, which is "Molex Common Data");

Step 111: generating EDI customer data based on the relationship diagram and non-EDI customer data through the macro;

Step 113: Send the EDI client data to the server, and the server integrates the EDI client data into the first EDI component (SI) of the EDI system.

Entities are suppliers, non-EDI customer data are non-EDI orders from mail or Excel, and EDI customer data is in CSV format.

The step 113 of sending EDI customer data to the server includes: saving the CSV order to the server through a macro, and the server sends the CSV order to the first EDI component (SI) of the EDI system by mail.

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

Step 109-1: receiving user's input via the INIT screen displayed on the user interface to create a relationship diagram;

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

The step 111 of generating EDI customer data based on the relationship diagram and the non-EDI customer data via the macro includes:

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

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

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

Step 109-2': If the mandatory field of the INIT screen has more than one value, then receive the user's input via the reference screen displayed on the user interface to create an interface between the format of the non-EDI customer data and the format of the EDI customer data The second relationship diagram of ;

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

By macro, the step 111 of generating EDI customer data based on the relationship graph between non-EDI customer data and EDI customer data includes:

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

According to another example, the step 107 of receiving customer profile data via a macro includes:

Step 107-1: receiving the user's selection on the options of using the existing customer profile for setup and manual setup;

Step 107-2: Whether a ready-made customer file is found in the file library;

Step 107-3: If yes, then load data from the archive to a local instance of the macro on the user terminal based on the customer profile login ID; and

Step 107-5: If not, receive the local instance of the macro input by the user on the user terminal.

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 disclosure.

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 the EDI system of an entity (such as a supplier), and the server includes:

processor;

display; and

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: open the macro provided by the server (order creation macro);

Step S205: Create a local instance of the macro on the user terminal through the macro;

Step S207: through the macro, based on the customer profile login ID, the customer profile data is loaded from the archive library to the local instance of the macro on the user terminal;

Step S209: After the user terminal generates the EDI client data based on the non-EDI client data, receive the EDI client data of the user terminal through the macro;

Step S211: Integrate the EDI customer data into the first EDI component (SI) of the EDI system.

Referring to Figure 4C, 020_PO update and CFM macros are used for non-EDI purchase order/firm order remake/confirmation.

The 020_PO update and CFM macro provide the following screen for the CSR's user terminal:

Init tab/screen

This screen contains the parameters needed to map customer supplied data with Molex SAP system data. Field values are stored in columns B, G, and H of the screen. Note: Values can be mandatory (red) or optional (black).

The screen is divided into four parts:

1) Control reference: This part includes the main parameters that enable the application to understand the user's output requirements.

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

Using SO# to update VA02? (yes/no) - If yes then SAP Update uses SO# else PO# and SoldTO.

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

2) Customer Open Open Order Reference: This section contains column indications/references to customer open order data. For example, if the user has provided a PO# in column "A", the field will contain "A2" which is the first PO value in the customer data.

3) Molex Open Order Reference: This section contains column indications/references to Molex open orders. For example, if the Molex SAP data extract has a PO# in column "A", the field will contain "A2" which is the first PO value in the Molex data.

4) Previous Customer Opened Open Order Reference: This section contains column indications/references to last week's Customer Open Order data. For example, if the user has provided a PO# in column "A", the field will contain "A2" which is the first PO value in the customer data.

Molex Open Outstanding Orders Tab/Screen

Actual data presented in Molex SAP for customers is extracted by CSR.

Customer opens outstanding order tab/screen

Data received from clients must be placed here by the CSR.

Previous customer opened incomplete order tab/screen

Data received from customers in the last week must be placed here by the CSR. This tab/screen is optional.

VA02 label/screen

This can be the output of the macro but does not have to be. Once the "Execute" button is clicked, the data generated on this screen is updated to SAP.

Proceed as follows. Load customer profile. Files are loaded in the same way as all other macros.

The CSR copies the most recent week of existing data on the "Customer Opens Open Orders" form to the "Previous Customers Open Open Orders" form, but it is not required.

CSR enters non-EDI customer data into the "Customer Open Open Order" screen.

The CSR pulls the existing data for the customer from SAP into the "Molex Open Open Order" screen.

Referring to Figure 8A, the CSR enters all required information on all parts of the "Initial" screen - Customer Open Open Order Reference, Control Reference, Molex Open Order Reference, and Previous Customer Open Where there is a commercial need for the analysis in the validation).

Once all of the above steps are completed, the CSR clicks on the "PO Change Macro" on the initial screen and/or thereafter clicks on the "PO Confirm Macro" button. This initiates PO change and/or subsequent PO confirmation execution. According to a further example, a Pivot table is generated. All analysis is done and flags are updated in the Customer Open Open Order screen. After analyzing and updating the flags, these arrows in Open Orders by Customers that match their respective Molex records and meet the criteria selected in the initial screen are moved to VA02 to be updated in SAP.

Referring to Figure 8B, once the CSR clicks the Execute button on the VA02 screen, the script to update the Purchase Order/Sales Order in SAP is executed if an existing SAP session is open. The application gives an error if there is no corresponding SAP session open. After updating the SAP for 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 (remake) and confirmation according to an exemplary embodiment of the present disclosure.

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 changes (remakes) and confirmations by integrating non-EDI customer data (non-EDI purchase order data) into an entity's EDI system.

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

User terminals include:

processor;

display; and

memory for storing instructions executable by the processor;

Wherein the processor is configured to perform a method comprising:

Step 301: log in to the 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: through the macro, based on the customer profile login ID, the customer profile data is loaded from the archive library to the local instance of the macro on the user terminal;

Step 309: On the local instance of the macro on the user terminal, via the macro, obtain the non-EDI customer data and the difference between the format of the non-EDI customer data and the format of the EDI customer data used by the second EDI component (SAP) of the EDI system relationship diagram;

Step 311: Generate EDI customer data based on the relationship diagram and non-EDI customer data through a macro;

Step 313: Directly update the EDI customer data to the second EDI component (SAP) of the EDI system through the macro.

Via a macro, step 313 of directly updating EDI customer data includes:

Step 313-1: Through the macro, open a session (SAP session) with the second EDI component of the EDI system connected to the supplier's own internal information system.

Step 313-2: Directly change or confirm the EDI customer data to the second EDI component (SAP) of the EDI system through the macro.

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

Step 309-1: receiving input from the user via the INIT screen displayed on the user interface to create a relationship graph;

Step 309-3: Receive EDI customer data for the existing EDI order from the second EDI component (SAP) via the Open Open Order screen (Molex Open Open Order) displayed on the user interface;

Step 309-5: Receive non-EDI customer data via the customer open outstanding order screen displayed on the user interface; and

The step 311 of generating EDI customer data based on the relationship diagram and the non-EDI customer data via the macro includes:

Step 311-1: Execute the change or confirmation of EDI customer data correspondingly through the PO change macro or PO confirmation macro on the INIT screen.

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

The server can implement the above order creation and the order change (remake) and confirmation described below.

Servers include:

processor;

display; and

memory for storing instructions executable by the processor;

Wherein the processor is configured to perform a method comprising:

Step 401: Receive a login request from a user terminal;

Step 403: open the macro provided by the server (order change and confirmation macro);

Step 405: Create a local instance of the macro on the user terminal through the macro;

Step 407: Load the customer profile data from the archive library to the local instance of the macro on the user terminal based on the customer profile login ID through the macro;

Step 409: after the user terminal generates the EDI client data based on the non-EDI client data, receive the EDI client data from the user terminal through the macro;

Step 411: Directly update the EDI customer data to the second EDI component of the EDI system through the macro.

The steps to update EDI customer data directly via macros include:

Step 411-1: through a macro, open a session (SAP session) with the second EDI component of the EDI system connected to the supplier's own internal information system; and

Step 411-3: Directly change or confirm the EDI customer data to the second EDI component of the EDI system through the macro.

Referring to Figure 4D, the 030_SA macro (forecast) is used to automate forecast analysis, billing, management, commitment of non-EDI bulk SA orders. It conducts analysis, tracks customer tendencies, proposes plans with quantities 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 disclosure.

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

User terminals include:

processor;

display; and

memory for storing instructions executable by the processor;

Wherein the processor is configured to perform a method comprising:

Step 501: log in to the server;

Step 503: open the macro (SA macro) provided by the server;

Step 505: Create a local instance of the macro on the user terminal through the macro;

Step 507: Loading the customer profile data from the archive library to the local instance of the macro on the user terminal through the macro based on the customer profile login ID;

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: Generate EDI customer data through macro;

Step 513: Send the EDI customer data to the EDI system as the analysis result through the macro.

The step 513 of sending the EDI customer data as analysis results to the EDI system via the macro includes at least one of the following steps:

Step 513-1: save the EDI customer data to the server through the macro; and

Step 513-3: Send the EDI customer data directly to the second EDI component (SAP) of the EDI system through the macro.

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 disclosure.

The server can implement the above order creation, order change (remake) and confirmation, and the prediction described below.

Servers include:

processor;

display; and

memory for storing instructions executable by the processor;

Wherein the processor is configured to perform a method comprising:

Step 601: Receive a login request from a user terminal;

Step 603: open the macro (SA macro) provided by the server;

Step 605: Create a local instance of the macro on the user terminal through the macro;

Step 607: Load the customer profile data from the archive library to the local instance of the macro on the user terminal based on the customer profile login ID through the macro;

Step 609: After the user terminal generates the EDI client data based on the non-EDI client data, receive the EDI client data from the user terminal through the macro.

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

The processing component 1302 generally controls the overall operations of the device 1300, such as those 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 complete all or part of the steps of the above method. Additionally, processing component 1302 may include one or more modules that facilitate interaction between processing component 1302 and other components. For example, processing component 1302 may include a multimedia module to facilitate interaction between multimedia component 1308 and processing component 1302 .

The memory 1304 is configured to store various types of data to support operations at the device 1300 . Examples of such data include instructions for any application or method operating on device 1300, contact data, phonebook data, 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 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 Disk.

The power supply component 1306 provides power to various components of the device 1300 . 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 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 touches, swipes, and gestures on the touch panel. The touch sensor may not only sense a boundary of a touch or swipe action, but also detect duration and pressure associated with the touch or swipe action. In some embodiments, multimedia component 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 capability.

The audio component 1310 is configured to output and/or input audio signals. For example, the audio component 1310 includes a microphone (MIC), which is configured to receive an external audio signal when the device 1300 is in an operation mode, such as a call mode, a recording mode, and a voice recognition mode. Received audio signals may be further stored in memory 1304 or sent via communication component 1316 . In some embodiments, the 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 a peripheral interface module, which may be a keyboard, a click wheel, buttons, and the like. These buttons may include, but are not limited to: a home button, volume buttons, start button, and lock button.

Sensor assembly 1314 includes one or more sensors for providing various aspects of status assessment for device 1300 . For example, the sensor component 1314 may detect the open/closed state of the device 1300, the relative positioning of components of the device 1300 (such as the display and keypad), changes in the position of the device 1300 or components of the device 1300, the presence or absence of user contact with the device 1300 Presence, orientation or acceleration/deceleration of the device 1300 and temperature changes of the device 1300. Sensor assembly 1314 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. Sensor assembly 1314 may also include optical sensors, such as CMOS or CCD image sensors, for use in imaging applications. In some embodiments, the sensor component 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 wired or wireless communication between the apparatus 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 one exemplary embodiment, the communication component 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 also includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on Radio Frequency Identification (RFID) technology, Infrared Data Association (IrDA) technology, Ultra Wide Band (UWB) technology, Bluetooth (BT) technology, and other technologies.

In an exemplary embodiment, apparatus 1300 may be implemented using one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable A gate array (FPGA), controller, microcontroller, microprocessor or other electronic component implementation for performing the methods described above.

In an exemplary embodiment, there is also provided a non-transitory computer-readable storage medium including instructions, such as the memory 1304 including instructions, which can be executed by the processor 1320 of the device 1300 to implement the above method. For example, the non-transitory computer readable storage medium may be ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, 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 disclosure. For example, device 1400 may be a server. Referring to FIG. 14 , apparatus 1400 includes a processing component 1422 that also includes one or more processors and a storage resource represented by memory 1432 for storing instructions executable by processing component 1422 , such as application programs. An application program stored in memory 1432 may include one or more modules, each corresponding to a set of instructions. Moreover, the processing component 1422 is configured to execute instructions to perform the above-described methods for integrating non-EDI customer data into an EDI system and/or analyzing non-EDI customer data with an EDI system.

The device 1400 may also include a power component 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 1478 . The device 1400 can run based on an operating system stored in the memory, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, and the like.

It should be understood that the present invention is not limited to the precise constructions which have been described above and shown in the accompanying drawings, and various modifications and changes may be made without departing from the scope thereof. The scope of the present invention is limited only by the appended claims.

Claims (20)

1. a kind of user terminal, for non-EDI customer data to be integrated into the EDI system an of entity, the user terminal Include:

Processor；

Display；And

Memory, for storing the instruction that can be executed by processor；

Wherein the processor is configured to execute:

Log on to server；

The macro of server offer is provided；

By described macro, the macro local example is created on the user terminal；

By described macro, the data of customer profile are received；

In the macro local example on the user terminal, by described macro, non-EDI customer data and non-EDI are obtained Relationship between the format of customer data and the format of the EDI customer data used by the first EDI component of the EDI system Figure；

By macro, EDI customer data is generated based on the relational graph and the non-EDI customer data；And

The server is sent by the EDI customer data, the EDI customer data is integrated into described by the server In the first EDI component of EDI system.

2. user terminal as described in claim 1, wherein

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

3. user terminal as claimed in claim 2, wherein sending the server for the EDI customer data includes:

By it is described it is macro the CSV order is saved in the server, the server is sent out the CSV order by mail It is sent to the first EDI component of the EDI system.

4. user terminal as claimed in claim 3, wherein

The macro local example is provided with user interface；

It is used by the macro format for obtaining non-EDI customer data and the non-EDI customer data and the first EDI component EDI customer data format between relational graph include:

Via the INIT screen shown in the user interface, the input of user is received, to create the relational graph；

Via the new PO screen shown in the user interface, the non-EDI customer data of user's input is received；And

It include: via described by the macro relational graph and the non-EDI customer data generation EDI customer data of being based on The CVS order shown in user interface is to IDOC screen, based on described in the relational graph and the non-EDI customer data generation CSV order.

5. user terminal as claimed in claim 3, wherein

The macro local example is provided with user interface；

It is used by the macro format for obtaining non-EDI customer data and the non-EDI customer data and the first EDI component Relational graph between the format of EDI customer data includes:

Via the INIT screen shown in the user interface, the input of user is received, to create the non-EDI customer data Format and EDI customer data format between the first relational graph；

If the mandatory field of the INIT screen has more than one value, via what is shown in the user interface Referring to screen, the input of user is received, to create between the format of the non-EDI customer data and the format of EDI customer data The second relational graph；

Via the new PO screen shown in the user interface, the non-EDI customer data of user's input is received；And

EDI client's number is generated by the macro relational graph based between the non-EDI customer data and the EDI customer data According to including: CVS order by being shown in the user interface to IDOC screen, based on first relational graph and described the Two relational graphs and the non-EDI customer data generate the CSV order.

6. user terminal as described in claim 1, wherein described to include: by the macro data for receiving customer profile

User is received about the selection of option for using existing customer's archives to be configured and be configured manually；

If finding ready-made customer profile in file store, it is based on customer profile login ID, data are loaded from file store The macro local example on to the user terminal；And

If not finding ready-made customer profile in file store, the input of user is received on the user terminal The macro local example.

7. a kind of server, for non-EDI customer data to be integrated into the EDI system an of entity, the server includes:

Processor；And

Memory, for storing the instruction that can be executed by processor；

Wherein the processor is configured to execute:

Receive the logging request for carrying out user terminal；

The macro of the server offer is provided；

By described macro, the macro local example is created on the user terminal；

By described macro, customer profile data are loaded on the user terminal from file store based on customer profile login ID The macro local example；

It is based on after non-EDI customer data generates EDI customer data in the user terminal, by described macro, receives the use The EDI customer data of family terminal；And

The EDI customer data is integrated into the first EDI component of EDI system.

8. server as claimed in claim 7, wherein

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

9. server as claimed in claim 8, wherein the EDI customer data is integrated into EDI system includes:

The CSV order is sent to by mail the first EDI component of the EDI system.

10. a kind of user terminal, for non-EDI customer data to be integrated into the EDI system an of entity, the user terminal Include:

Processor；

Display；And

Memory, for storing the instruction that can be executed by processor；

Wherein the processor is configured to execute:

Log on to server；

The macro of the server offer is provided；

By described macro, the macro local example is created on the user terminal；

By described macro, customer profile data are loaded on the user terminal from file store based on customer profile login ID The macro local example；

By described macro, in the macro local example on the user terminal, non-EDI customer data and non-is obtained Relational graph between the format of EDI customer data and the format of the EDI customer data used by the 2nd EDI component of EDI system；

By described macro, EDI customer data is generated based on the relational graph and the non-EDI customer data；And

By described macro directly by EDI customer data update into the 2nd EDI component of the EDI system.

11. user terminal as claimed in claim 10, wherein

The entity is supplier；And

It macro directly update the EDI customer data by described and includes:

By described macro, the session of opening and the 2nd EDI component of the EDI system, the EDI system is connected to described The insider information system of supplier oneself；And

By described macro, directly the EDI customer data is changed or is confirmed the 2nd EDI component of the EDI system.

12. user terminal as claimed in claim 11, wherein

The macro local example is provided with user interface；

Pass through the macro format and the 2nd EDI component for obtaining the non-EDI customer data and the non-EDI customer data Relational graph between the format of the EDI customer data used includes:

Via the INIT screen shown in the user interface, the input of user is received, to create the relational graph；

Via the opening backlog screen shown in the user interface, existing EDI is received from the 2nd EDI component The EDI customer data of order；

Via the opening backlog screen shown in the user interface, the non-EDI customer data is received；And

By described macro, generating EDI customer data based on the relational graph and the non-EDI customer data includes: via in institute Stating PO on INIT screen, to change macro or PO confirmation macro, to correspond to the change or confirmation that execute EDI customer data.

13. a kind of server, for non-EDI customer data to be integrated into the EDI system an of entity, the server packet It includes:

Processor；And

Memory, for storing the instruction that can be executed by processor；

Wherein the processor is configured to execute:

Receive the logging request for carrying out user terminal；

The macro of the server offer is provided；

By described macro, the macro local example is created on the user terminal；

By described macro, customer profile data are loaded on the user terminal from file store based on customer profile login ID The macro local example；

After the user terminal is based on the non-EDI customer data generation EDI customer data, by described macro, from The user terminal receives EDI customer data；And

By described macro, directly the EDI customer data is updated into the 2nd EDI component of EDI system.

14. server as claimed in claim 13, wherein

The entity is supplier；And

It macro directly update the EDI customer data by described and includes:

By described macro, the session of opening and the 2nd EDI component of the EDI system, the EDI system is connected to supplier certainly Oneself insider information system；And

By described macro, the EDI customer data is directly changed or is confirmed the 2nd EDI component.

15. a kind of user terminal, using the non-EDI customer data of the EDI network analysis of an entity, the user terminal includes:

Processor；

Display；And

Memory, for storing the instruction that can be executed by processor；

Wherein the processor is configured to execute:

Log on to server；

The macro of the server offer is provided；

Macro macro local example is created on the user terminal by described；

By described macro, customer profile data are loaded on the user terminal from file store based on customer profile login ID The macro local example；

By described macro on the user terminal, in the macro local example in the custom system, receive The non-EDI customer data of input；

Pass through the macro generation EDI customer data；And

By it is described it is macro using the EDI customer data as analysis result be sent to EDI system.

16. user terminal as claimed in claim 15, wherein

The entity is supplier, and the non-EDI customer data is non-EDI batch SA order, and the EDI customer data is CSV Format.

17. user terminal as claimed in claim 16, wherein by described macro, tied the EDI customer data as analysis Fruit is sent to EDI system and at least one of includes the following steps:

By described macro, the EDI customer data is saved in the server；And

By described macro, directly it sends the EDI customer data to the 2nd EDI component of the EDI system.

18. a kind of server, for the non-EDI customer data of EDI network analysis using an entity, the server includes:

Processor；And

Memory, for storing the instruction that can be executed by processor；

Wherein the processor is configured to execute:

Receive the logging request for carrying out user terminal；

The macro of server offer is provided；

By macro, macro local example is created on the subscriber terminal；

By described macro, customer profile data are loaded on the user terminal from file store based on customer profile login ID The macro local example；And

After the user terminal is based on non-EDI customer data generation EDI customer data, by described macro, from the user Terminal receives EDI customer data as analysis result.

19. server as claimed in claim 18, wherein

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

20. server as claimed in claim 19, wherein by described macro from user terminal reception EDI client's number Further include at least one of following step after as analysis result:

By described macro, the EDI customer data is sent in mail, which will issue client by user；

By described macro, the non-EDI customer data is automatically extracted in the report of the main fluctuation in shared platform；And

By described macro, the EDI customer data is received to the first EDI component of the EDI system；

By described macro, directly the EDI customer data is uploaded in the 2nd EDI component of the EDI system.