KR102501140B1 - System and method for streamlining the selection process to improve scalability - Google Patents

Abstract

A computer implemented system for processing returns without receiving items to minimize network load is disclosed. The system includes at least one non-transitory computer readable medium configured to store instructions and at least one processor configured to execute the instructions to perform an action, the action comprising removing unwanted items from a user device. Receiving a return API (application programming interface) call requesting a return, validating the return API call against a data record in a networked database, parameters associated with the returned item and reasons included in the return API call. Comparing codes, generating a refund API call to process the return API call based on the result of the comparison, triggering an update to the data record in the networked database to record a refund. A computer-implemented system is disclosed that includes the operation of sending a notification to the user device in response to the refund API call. In addition to this, various embodiments identified through the specification are possible.

Description

System and method for streamlining the selection process to improve scalability

This disclosure relates generally to computer systems and methods for streamlining the selection process to improve scalability. In particular, one embodiment of the present disclosure relates to an inventive and unique system for identifying a subset of electronic requests that can benefit from a more streamlined process that can reduce network load and improve scalability.

Advances in computer networking have moved many disparate processes online enabling rapid and remote processing and automation. In particular, an increase in business processes that required human intervention are now conducted online to the point where hundreds of thousands or even millions of transactions can occur daily within a company's network.

These transactions are typically implemented using Application Programming Interfaces (APIs) that enable communication between different systems, sub-systems, and modules. Communications that use APIs to process transactions, also known as API calls, are often small (e.g., less than a few hundred bytes) and do not impose a significant load on the network. Additionally, advances in network communication that enable faster data transmission ensure that networks can support large loads.

However, problems arise as more systems, sub-systems or modules are added to the network to specialize in specific tasks and as the number of those involved in completing a transaction increases. For example, a simple request to return a product to an online shopping mall may include the following API calls. system receiving the return request; system for managing initial orders; systems that process payment for orders; system for managing return shipments; systems for receiving and restocking returned items; Not only these, but the subsystems and modules that function in conjunction with these systems. This problem is exacerbated when the network has to support millions of users or transactions per day. Even API calls as small as 100 bytes can quickly scale and hog down a network.

For each new transaction (e.g. order processing), the network load created by simply applying the same set of API calls involving the same number of systems and sub-systems grows linearly as the number of new requests increases. will only increase An exponential increase in users and the transactions they generate can lead to an exponential increase in network load, which can quickly strain the network. Therefore, the set of API calls must be optimized to reduce network load and improve scalability to meet growing demand.

One aspect of the present disclosure relates to a computer implemented system for processing returns without receiving items to minimize network load. The system includes at least one non-transitory computer readable medium configured to store instructions and at least one processor configured to execute the instructions to perform operations. The operation is to receive a return API call requesting return of the unwanted item from the user device, to verify the return API call against the data record of the networked database, and to call the parameter and return API associated with the returned item. Comparing the reason codes contained in the comparison, generating a refund API call to process the return API call based on the result of the comparison, triggering an update to the data record in the networked database to record the refund. operation, and an operation of transmitting a notification to a user device in response to a refund API call.

Another aspect of the present disclosure relates to a method for a computer implemented method for processing a return without receiving an item to minimize network load. The method includes an operation of receiving a return API call requesting return of an unwanted item from a user device, an operation of verifying the return API call with respect to a data record of a networked database, an operation of verifying the return API call, and parameters related to the returned item and the return API. Comparing the reason codes included in the call, generating a refund API call to process the return API call based on the result of the comparison, triggering an update to the data record in the networked database to record the refund. ), and transmitting a notification to the user device in response to a refund API call.

Another aspect of the present disclosure relates to a computer implemented system for processing returns without receiving items to minimize network load. The system includes at least one non-transitory computer readable medium configured to store instructions and at least one processor configured to execute the instructions to perform operations. The operations include receiving a return API call requesting return of the returned item from the user device, verifying the return API call against data records in a networked database, and returning the category identifier associated with the returned item. It may include an operation of comparing reason codes included in API calls. If the category identifier is acceptable with respect to the reason code, the actions are to send a refund API call to the payment management system, update the data record in the networked database to record the refund, and authorize the return API call. An operation of transmitting a notification to a user device may be further included. If the category identifier is not acceptable with respect to the reason code, the action is to make a retrieval API call requesting retrieval of the returned item, capture the item identifier of the returned item upon retrieval of the returned item, and return Updating a data record in a networked database to record the number of returned items, sending a refund API call to a payment management system, and sending a notification about approval of the refund API call to a user device. can

Also discussed herein are other systems, methods, and computer readable media.

1A is a schematic block diagram illustrating an exemplary embodiment of a network including a computer system for communications enabling delivery, transportation, and logistics operations, in accordance with disclosed embodiments.
FIG. 1B is a diagram illustrating a sample of a Search Results Page (SRP) that includes one or more search results that satisfy a search request in accordance with an interactive user interface element, in accordance with a disclosed embodiment.
FIG. 1C is a diagram illustrating a sample of a Single Detail Page (SDP) including products and information about products along with interactive user interface elements, in accordance with a disclosed embodiment.
1D is a sample diagram of a shopping cart page that includes items in a virtual shopping cart according to interactive user interface elements, in accordance with disclosed embodiments.
1E is a diagram illustrating a sample of an order page including a virtual shopping cart and information regarding purchases and delivery, in accordance with interactive user interface elements, in accordance with disclosed embodiments.
2 is a schematic diagram of an exemplary fulfillment center configured to utilize the disclosed computer system, in accordance with a disclosed embodiment.
3A shows an exemplary pictographic representation of an intake sub-system 300, in accordance with a disclosed embodiment.
3B shows an exemplary pictographic representation of output sub-system 325, in accordance with the disclosed embodiment.
3C illustrates an exemplary pictographic representation of a control sub-system, an exemplary returning event store, an exemplary rules engine, and an exemplary external data source, in accordance with a disclosed embodiment.
3D shows an exemplary pictographic representation of a workflow sub-system 375, in accordance with a disclosed embodiment.
4 shows an exemplary pictographic representation of a network environment 400 for return processing using the presently disclosed embodiment.
5 depicts an exemplary flow diagram of a computerized process for processing returns, in accordance with a disclosed embodiment.
6 depicts an exemplary flow diagram of a computerized process for processing a refund, in accordance with a disclosed embodiment.

The following detailed description refers to the accompanying drawings. Wherever possible, the same reference numbers are used to refer to the same or similar parts in the drawings and the following description. Although several exemplary embodiments are described herein, variations, adaptations, and other implementations are possible. For example, substitutions, additions, or variations may be made to the components and steps shown in the drawings, and the exemplary methods described herein substitute, rearrange, or remove steps relative to the disclosed methods. Or it can be modified by adding. Accordingly, the detailed description below is not limited to the disclosed embodiments and examples. Instead, the proper scope of the invention is defined by the appended claims.

Embodiments of the present disclosure are systems and methods configured to identify a subset of electronic requests that can benefit from a more streamlined process, thus reducing load on the overall network and improving scalability. It is about. Compared to existing or existing processes, the simplified process may be advantageous in that it requires less resources such as network load, computing power, and/or working time.

Referring to FIG. 1A , a schematic block diagram 100 illustrating an embodiment of a system including a computer system for communications enabling delivery, transportation and logistics operations is shown. As shown in FIG. 1A , system 100 may include a variety of systems, each of which may be interconnected through one or more networks. The systems may also be connected to each other via an integrated connection, for example using a cable. The illustrated systems include a shipment authority technology (SAT) system 101, an external front end system (103), an internal front end system 105, a transportation system 107, and a mobile device 107A. , 107B, 107C), merchant portal 109, shipment and order tracking (SOT) system 111, fulfillment optimization (FO) system 113, fulfillment messaging gateway gateway, FMG) 115, supply chain management (SCM) system 117, warehouse management system (WMS) 119, mobile devices 119A, 119B, 119C (fulfillment center (shown as being within a fulfillment center (FC) 200), a third party fulfillment system (121A, 121B, 121C), a fulfillment center authorization system (FC Auth) 123, and A labor management system (LMS) 125 is included.

In some embodiments, SAT system 101 may be implemented as a computer system that monitors order status and delivery status. For example, the SAT system 101 can determine if an order has passed its Promised Delivery Date (PDD), initiate a new order, reship items in undelivered orders, and deliver undelivered items. take appropriate action, including canceling unsolicited orders and initiating contact with the ordering customer. The SAT system 101 may also monitor other data, including outputs (such as the number of packages shipped over a specified period of time), and inputs (such as the number of empty cardboard boxes received for use in delivery). . The SAT system 101 also enables communication (e.g., using store-and-forward or other techniques) between devices such as the external front-end system 103 and the FO system 113. can act as a gateway between different devices in the system 100.

In some embodiments, external front end system 103 may be implemented as a computer system that allows external users to interact with one or more systems within system 100 . For example, in an embodiment where system 100 enables presentation of a system that allows a user to place an order for an item, external front end system 103 receives a search request, presents a page of items, and , can be implemented as a web server requesting payment information. For example, external front-end system 103 may be implemented as a computer or computers running software such as Apache HTTP Server, Microsoft Internet Information Services (IIS), NGINX, and the like. In another embodiment, external front-end system 103 receives and processes requests from external devices (e.g., mobile device 102A or computer 102B) and, based on these requests, stores databases and other data. It may run custom web server software designed to obtain information from and provide responses to received requests based on the obtained information.

In some embodiments, external front end system 103 may include one or more of a web caching system, a database, a search system, or a payment system. In one aspect, external front-end system 103 may include one or more of these systems, while in another aspect, external front-end system 103 may have interfaces (e.g., servers) connected to one or more of these systems. server-to-server, database-to-database, or other network connections).

An exemplary set of steps represented by FIGS. 1B, 1C, 1D and 1E will help explain some operation of the external front end system 103. External front end system 103 may receive information from systems or devices within system 100 for presentation and/or display. For example, the external front-end system 103 may include a Search Result Page (SRP) (eg, FIG. 1B), a Single Detail Page (SDP) (eg, FIG. 1C), One or more web pages may be hosted or provided, including a cart page (eg, FIG. 1D), or an order page (eg, FIG. 1E). A user device (eg, using mobile device 102A or computer 102B) can request a search by going to external front end system 103 and entering information into the search box. External front end system 103 can request information from one or more systems within system 100 . For example, the external front-end system 103 may request information satisfying a search request from the FO system 113. External front-end system 103 may also request and receive (from FO system 113) a Promised Delivery Date or "PDD" for each product included in the search results. In some embodiments, the PDD is an estimate of when a package containing the product will arrive at the user's desired location, or a product at the user's desired location, if ordered within a specified time period, for example, by the end of the day (PM 11:59). It can indicate the date on which this is promised to be delivered. (PDD is discussed further below with respect to FO system 113.)

The external front-end system 103 may prepare an SRP (eg, FIG. 1B) based on the information. The SRP may contain information that satisfies the search request. For example, this may include photos of products that satisfy the search request. The SRP may also include information about each price for each product, or enhanced delivery options, PDD, weight, size, offers, discounts, etc. for each product. The external front-end system 103 may send the SRP (eg, over the network) to the requesting user device.

The user device can then select a product from the SRP, for example by clicking or tapping the user interface to select the product shown in the SRP, or using another input device. The user device may make a request for information about the selected product and send it to the external front end system 103 . In response, the external front end system 103 may request information about the selected product. For example, the information may include additional information beyond what is presented for the product on each SRP. This may include, for example, expiration date, country of origin, weight, size, number of items in the package, handling instructions, or other information about the product. Information may also include recommendations for similar products (e.g., based on big data and/or machine learning analysis of customers who have purchased this product and at least one other product), answers to frequently asked questions, customer reviews, manufacturing You can include business information, photos, and more.

The external front-end system 103 may prepare a Single Detail Page (SDP) (eg, FIG. 1C ) based on the received product information. The SDP may also include other interactive elements, such as a "Buy Now" button, "Add to Cart" button, quantity field, item picture, and the like. The SDP may further include a list of vendors offering products. The listing may be ordered based on the price offered by each seller so that the seller offering to sell the product at the lowest price is listed at the top. The listing may also be ordered based on seller ranking so that the highest ranked seller is listed at the top. The seller ranking may be made based on multiple factors including, for example, past tracking history of sellers meeting the suggested PDD. The external front-end system 103 may forward the SDP to the requesting user device (eg, over the network).

The requesting user device may receive an SDP listing product information. Upon receiving the SDP, the user device can interoperate with the SDP. For example, the user of the requesting user device may click on or interact with the "Place in Cart" button of the SDP. This adds the product to the shopping cart associated with the user. The user device may send this request to the external front end system 103 to add the product to the shopping cart.

The external front end system 103 may generate the shopping cart page (eg, FIG. 1D). In some embodiments, the shopping cart page lists products that the user has added to a virtual “shopping cart”. The user device may request the shopping cart page by clicking or interacting with the icon of the SRP, SDP, or other page. In some embodiments, the shopping cart page includes all products that the user has added to the shopping cart, as well as the quantity of each product, the price per item of each product, the price of each product based on the associated quantity, information about the PDD, delivery method, shipping cost, User interface elements for modifying products in the shopping cart (e.g., deleting or modifying quantities), options for ordering other products or setting regular delivery of products, options for setting up interest payments, purchasing You can list information about the products in the shopping cart, such as user interface elements to proceed. A user of a user device may click on or interact with a user interface element (eg, a button that says “Buy Now”) to initiate a purchase of a product in a shopping cart. If so, the user device may send this request to the external front end system 103 to initiate the purchase.

External front end system 103 may generate an order page (eg, FIG. 1E ) in response to receiving a request to initiate a purchase. In some embodiments, the order page re-lists items from the shopping cart and requests entry of payment and shipping information. For example, the order page may include information about the buyer of the items in the shopping cart (eg, name, address, email address, and phone number), and information about the recipient (eg, name, address, phone number, and delivery information). , shipping information (eg, speed/method of delivery and/or pickup), payment information (eg, credit card, bank transfer, check, stored credit), user interface elements requesting a cash receipt (eg, tax purposes), etc. The external front end system 103 may send the order page to the user device.

The user device can enter information on the order page and click or interact with user interface elements that send the information to the external front-end system 103 . From there, external front end system 103 transmits information to other systems within system 100 to create and process new orders with products in the shopping cart.

In some embodiments, external front-end system 103 may be further configured to allow merchants to send and receive information related to orders.

In some embodiments, internal front-end system 105 allows internal users (eg, employees of an organization that owns, operates, or leases system 100) to interact with one or more systems within system 100. It can be implemented as a computer system. For example, in an embodiment where system 100 enables a presentation of the system to allow a user to place an order for an item, internal front end system 105 allows an internal user to view diagnostic and statistical information about an order. It can be implemented as a web server that allows you to view, edit item information, or review statistics about an order. For example, internal front-end system 105 may be implemented as a computer or computers running software such as Apache HTTP Server, Microsoft Internet Information Services (IIS), NGINX, and the like. In another embodiment, internal front-end system 105 receives and processes requests from systems or devices represented within system 100 (as well as other devices not shown) and, based on such requests, stores databases and other data. It may run custom web server software designed to obtain information from and provide responses to received requests based on the obtained information.

In some embodiments, internal front end system 105 may include one or more of a web caching system, database, search system, payment system, analytics system, order monitoring system, and the like. In one aspect, internal front-end system 105 may include one or more of these systems, while in another aspect internal front-end system 105 may have interfaces (e.g., server-to-server interfaces) connected to one or more of these systems. server, database-to-database, or other network connection).

In some embodiments, transportation system 107 may be implemented as a computer system that enables communication between systems or devices within system 100 and mobile devices 107A-107C. In some embodiments, transport system 107 may receive information from one or more mobile devices 107A-107C (eg, cell phones, smart phones, PDAs, etc.). For example, in some embodiments, mobile devices 107A-107C may include devices operated by deliverymen. A delivery man, who may be a full-time, temporary, or shift worker, may use the mobile device 107A-107C to deliver a package containing a product ordered by the user. For example, to deliver a package, the delivery man may receive a notification on the mobile device indicating the package to be delivered and the location to deliver. Upon arrival at the delivery location, the delivery man can find the package (eg in the back of a truck or in a crate of packages) and, using a mobile device, data related to the identifier on the package (eg barcode, image, string, RFID tag, etc.) and deliver the package (eg, by placing it on a front door, leaving it with a security guard, handing it off to a recipient, etc.). In some embodiments, the delivery person may take a picture(s) of the package and/or obtain a signature using the mobile device. The mobile device may send information to transportation system 107 including information about the delivery including, for example, time, date, GPS location, photo(s), identifier associated with the delivery person, identifier associated with the mobile device, and the like. can Transportation system 107 may store this information in a database (not shown) for access by other systems within system 100 . In some embodiments, transportation system 107 may use this information to prepare and transmit tracking data indicating the location of a particular package to other systems.

In some embodiments, a particular user may use one type of mobile device (eg, a full-time employee may use a specialized PDA with custom hardware such as a barcode scanner, stylus, and other devices) while other users may use different types of mobile devices (eg, temporary or shift workers may use off-the-shelf cell phones and/or smart phones).

In some embodiments, transport system 107 may associate a user with each device. For example, the transportation system 107 may associate a user (e.g., represented by a user identifier, employee identifier, or phone number) and a mobile device (e.g., International Mobile Equipment Identity (IMEI), International Mobile Subscription Identifier (e.g., IMSI), phone number, Universal Unique Identifier (UUID), or Globally Unique Identifier (GUID)). Transportation system 107 may use these associations with data received upon delivery to analyze the data stored in the database to determine, among other things, the location of the operator, the efficiency of the operator, or the speed of the operator.

In some embodiments, merchant portal 109 may be implemented as a computer system that allows a merchant or other external entity to communicate electronically with one or more systems within system 100 . For example, the seller uses a computer system (not shown) to upload or provide product information, order information, contact information, etc. for products that the seller intends to sell through the system 100 using the seller portal 109. Available.

In some embodiments, shipping and order tracking system 111 receives, stores, and receives information about the location of packages containing products ordered by a customer (eg, a user using devices 102A-102B). It can be implemented as a forwarding computer system. In some embodiments, the delivery and order tracking system 111 may request or store information from a web server (not shown) operated by a delivery company that delivers packages containing products ordered by customers.

In some embodiments, delivery and order tracking system 111 may request and store information from systems represented in system 100 . For example, shipping and order tracking system 111 may request information from transportation system 107 . As noted above, transportation system 107 may be configured to provide one or more mobile devices 107A-107C (eg, a mobile phone) associated with one or more of a user (eg, delivery man) or vehicle (eg, delivery truck). , smart phone, PDA, etc.) can receive information. In some embodiments, shipment and order tracking system 111 may also use a warehouse management system (WMS) 119 to determine the location of individual products within a fulfillment center (eg, fulfillment center 200). You can request information from Shipment and order tracking system 111 requests data from one or more of transportation system 107 or WMS 119, processes it, and sends it to a device (eg, user device 102A, 102B) upon request. can provide

In some embodiments, fulfillment optimization (FO) system 113 may send information about customer orders from other systems (eg, external front-end system 103 and/or shipping and order tracking system 111). It can be implemented as a computer system that stores. FO system 113 may also store information indicating where a particular item is maintained or stored. For example, a particular item may be stored in only one fulfillment center, while another particular item may be stored in multiple fulfillment centers. In another embodiment, a particular fulfillment center may be configured to store only a particular set of items (eg, fresh produce or frozen products). The FO system 113 stores this information as well as related information (eg, quantity, size, date received, expiration date, etc.).

FO system 113 may also calculate a corresponding Promised Delivery Date (PDD) for each product. In some embodiments, PDD may be based on one or more elements. For example, FO system 113 may determine past demand for a product (e.g., how much that product has been ordered over a period of time), predicted demand for a product (e.g., how many customers will have a product in an upcoming period) expected to be ordered), historical demand across the network indicating how many products were ordered over a period of time, projected demand across the network indicating how many products are expected to be ordered during the upcoming period, and storing each product The PDD for a product may be calculated based on the number of one or more products stored in each fulfillment center 200, expectations or current orders for that product, and the like.

In some embodiments, FO system 113 periodically (eg, hourly) determines the PDD for each product, and searches or other systems (eg, external front-end system 103, SAT system ( 101), and store it in a database for transmission to the shipping and order tracking system 111). In another embodiment, FO system 113 receives electronic requests from one or more systems (eg, external front end system 103, SAT system 101, shipping and order tracking system 111) and responds to the request. PDD can be calculated according to

In some embodiments, fulfillment messaging gateway (FMG) 115 receives requests or responses in one format or protocol from one or more systems in system 100, such as FO system 113, and sends them in another format or protocol. , and forwards it to another system, such as the WMS 119 or the third party fulfillment system 121A, 121B, or 121C, in the converted format or protocol, and vice versa. .

In some embodiments, supply chain management (SCM) system 117 may be implemented as a computer system that performs predictive functions. For example, the SCM system 117 may store, for example, past demand for a product, predicted demand for the product, network-wide past demand, network-wide predicted demand, and stored in each fulfillment center 200. Based on the number of products, expectations or current orders for each product, the level of demand for a particular product can be predicted. In response to these predicted levels and quantities of each product in all fulfillment centers, the SCM system 117 may create one or more purchase orders and stock a sufficient amount to satisfy the predicted demand for a particular product.

In some embodiments, warehouse management system (WMS) 119 may be implemented as a computer system that monitors workflow. For example, WMS 119 may receive event data representing individual events from individual devices (eg, devices 107A-107C or 119A-119C). For example, WMS 119 may receive event data indicating the use of one of these devices to scan a package. As discussed below with respect to fulfillment center 200 and FIG. 2 , during the fulfillment process, the package identifier (eg, barcode or RFID tag data) is transferred to a machine (eg, automated or handheld) at a particular step. barcode scanner, RFID reader, high-speed camera, tablet 119A, mobile device/PDA 119B, computer 119C, etc.). WMS 119 may store each event representing a scan or read of a package identifier in a corresponding database (not shown) along with the package identifier, time, date, location, user identifier, or other information, and transfer this information to other systems. (eg, delivery and order tracking system 111).

In some embodiments, WMS 119 may store information associating one or more devices (eg, devices 107A-107C or 119A-119C) with one or more users associated with system 100 . For example, in some situations, a user (such as a part-time or full-time employee) may be associated with a mobile device in that it owns it (eg, the mobile device is a smartphone). In another situation, a user temporarily stores a mobile device (e.g., a user who rents a mobile device from the start of the day, uses it for the day, and returns it at the end of the day) may be related to

In some embodiments, WMS 119 may maintain an activity log for each user associated with system 100. For example, WMS 119 may perform any assigned process (e.g., unload truck, pick up item at pick-up area, rebin wall task, pack item), user identifier, location (e.g. For example, a floor or area of fulfillment center 200), a number of units moved through the system by an employee (eg, number of items picked up, a number of packed items), a device (eg, number of items picked up, a number of packed items), For example, information associated with each employee including identifiers associated with devices 119A-119C) may be stored. In some embodiments, WMS 119 may receive check-in and check-out information from a timekeeping system, such as a timekeeping system operated on devices 119A-119C.

In some embodiments, third party fulfillment (3PL) systems 121A-121C represent computer systems associated with third party providers of logistics and products. For example, some products may be stored at fulfillment center 200 (as described below with respect to FIG. 2) while other products may be stored off-site, or on demand. It may be produced or may not otherwise be stored in the fulfillment center 200 . 3PL systems 121A-121C may be configured to receive orders from FO system 113 (eg, via FMG 115) and deliver products and/or services (eg, delivery or installation) can be provided. In some embodiments, one or more 3PL systems 121A-112C may be part of system 100, while in other embodiments, one or more 3PL systems 121A-112C may exist external to system 100. (eg, owned or operated by a third party provider).

In some embodiments, the fulfillment center authentication system (FC Auth) 123 may be implemented as a computer system with various functions. For example, in some embodiments, FC Auth 123 may act as a single-sign on (SSO) service to one or more other systems within system 100 . For example, FC Auth 123 allows the user to log in through the internal front-end system 105, determines that the user has similar permissions to access resources in the delivery and order tracking system 111, and , you can give users access to those privileges without requiring a second login process. In another embodiment, FC Auth 123 may allow a user (eg, employee) to associate themselves with a specific task. For example, some employees may not have an electronic device (such as devices 119A-119C) and instead may move between jobs and between areas within the fulfillment center 200 during the day. FC Auth 123 can be configured to indicate what these employees are doing at different times of the day and which zones they belong to.

In some embodiments, labor management system (LMS) 125 may be implemented as a computer system that stores attendance and overtime information for employees (including full-time and part-time employees). For example, LMS 125 may receive information from FC Auth 123, WMS 119, devices 119A-119C, transport system 107, and/or devices 107A-107C.

The specific configuration shown in FIG. 1A is by way of example only. For example, while FIG. 1A shows FC Auth system 123 coupled to FO system 113, not all embodiments require this particular configuration. Indeed, in some embodiments, the systems within system 100 may be used in the Internet, intranets, wide-area networks (WANs), metropolitan-area networks (MANs), wireless networks conforming to IEEE 802.11a/b/g/n standards, leased They may be connected through one or more public or private networks including circuits and the like. In some embodiments, one or more systems within system 100 may be implemented as one or more virtual servers implemented in a data center, server farm, or the like.

2 shows a fulfillment center 200 . Fulfillment center 200 is an example of a physical location that stores items for delivery to customers upon order. The fulfillment center (FC) 200 can be divided into a number of zones, each of which is shown in FIG. 2 . In some embodiments, these "zones" can be thought of as virtual divisions between different steps in the process of receiving an item, storing an item, retrieving an item, and shipping the item. Thus, while “zones” are shown in FIG. 2, in some embodiments other divisions of zones are possible, and the zones of FIG. 2 may be omitted, duplicated, or modified.

The inbound zone 203 represents an area of the FC 200 where items are received from vendors who wish to sell products using the system 100 of FIG. 1A. For example, a vendor may use a truck 201 to deliver items 202A and 202B. Item 202A may represent a single item large enough to occupy its own shipping pallet, while item 202B may represent a set of items stacked together on the same pallet to save space. .

An operator may receive an item in the inbound area 203 and optionally check the item for damage and correctness using a computer system (not shown). For example, an operator may use the computer system to compare the quantity of items 202A, 202B to the ordered quantity of the items. If the quantities do not match, the operator may reject one or more of the items 202A and 202B. If the quantities match, the operator can transport the items (eg, by dolly, handtruck, forklift, or manually) to the buffer area 205 . Buffer zone 205 may be a temporary storage area for items that are not currently needed in a pickup zone, for example because there are sufficient quantities of those items in the pickup zone to meet predicted demand. In some embodiments, forklift 206 operates to transport items around buffer zone 205 and between inbound zone 203 and drop zone 207 . If items 202A, 202B are needed at the pick-up area (eg, due to predicted demand), the forklift may transport the items 202A, 202B to the drop area 207 .

Drop zone 207 may be an area of FC 200 where items are stored prior to being transported to pickup zone 209 . An operator assigned to a pickup operation ("picker") accesses an item 202A, 202B in the pickup area, scans a barcode for the pickup area, and retrieves a mobile device (e.g., device 119B). can be used to scan barcodes associated with items 202A and 202B. The picker may then take the item to the pick-up area 209 (eg, by placing the item on a cart or carrying it).

Pickup area 209 may be an area of FC 200 where item 208 is stored in storage unit 210 . In some embodiments, storage unit 210 may include one or more of a physical shelf, bookshelf, box, tote, refrigerator, freezer, cold storage, or the like. In some embodiments, pickup area 209 may be organized into multiple floors. In some embodiments, a worker or machine may pick up an item from area 209 in a variety of ways, including, for example, a forklift, elevator, conveyor belt, cart, hand truck, wheelbarrow, automated robot or device, or manual operation. can be transported to For example, a picker can drop items 202A and 202B on a hand truck or cart in drop zone 207 and take items 202A and 202B to pickup zone 209 .

A picker may receive a command to place (or “stow”) an item in a particular spot in the pick-up area 209 , such as a particular space on the storage unit 210 . For example, the picker may scan item 202A using a mobile device (eg, device 119B). The device may indicate where the item 202A should be loaded, for example, using aisles, shelves, and position indicating systems. The device can then have the picker scan the barcode at that location before loading item 202A at that location. The device may transmit data (e.g., over a wireless network) to a computer system, such as WMS 119 of FIG. 1A, indicating that item 202A has been loaded into its location by a user using device 119B. .

Once the user places an order, the picker may receive instructions to device 119B to retrieve one or more items 208 from storage unit 210 . The picker may retrieve the item 208, scan the barcode on the item 208, and place it on the vehicle 214. In some embodiments, transport device 214 is represented as a slide, but transport device may be implemented as one or more of a conveyor belt, elevator, cart, forklift, hand truck, wheelbarrow, and the like. Item 208 may then arrive at packing area 211 .

Packing area 211 may be the area of FC 200 where items are received from pick-up area 209 and packed into boxes or bags for final shipment to customers. At the packing area 211, a worker assigned to receive the item ("rebin worker") will receive the item 208 from the pickup area 209 and determine which order it corresponds to. For example, a liveine worker may use a device such as computer 119C to scan a barcode on item 208 . Computer 119C may visually indicate which order item 208 is associated with. This may include, for example, spaces or "cells" on the wall 216 corresponding to orders. Once the order is complete (eg, because the cell contains all the items in the order), the liveine operator can notify the packer (or "packer") that the order is complete. A packer can retrieve items from the cell and place them in a box or bag for shipping. The packer may then direct the boxes or bags to the hub area 213 via, for example, a forklift, cart, wheelbarrow, hand truck, conveyor belt, hand or other method.

The hub area 213 may be an area of the FC 200 that receives all boxes or bags (“packages”) from the packing area 211 . Workers and/or machines in the hub area 213 can retrieve the packages 218, determine which part of the delivery area each package is to be delivered to, and direct the packages to the appropriate camp area 215. For example, if a delivery area has two small sub-areas, the package will be sent to one of the two camp areas 215. In some embodiments, an operator or machine may scan the package (eg, using one of devices 119A-119C) to determine its final destination. Sending a package to a camp area 215 may, for example, determine the portion of the geographic area the package is destined for (e.g., based on zip code), and determine the camp area 215 associated with the portion of the geographic area. may include doing

In some embodiments, camp zone 215 may include one or more buildings, one or more physical spaces, or one or more areas from which packages are received from hub zone 213 for classification into routes and/or sub-routes. can In some embodiments, camp area 215 is physically separate from FC 200 , while in other embodiments camp area 215 may form part of FC 200 .

Workers and/or machines in camp area 215 may, for example, compare destinations with existing routes and/or sub-routes, calculate workloads for each route and/or sub-route, time of day, delivery method. , the cost to ship the package 220, the PDD associated with the item in the package 220, and the like, may determine which route and/or sub-route the package 220 should be associated with. In some embodiments, an operator or machine may scan the package (eg, using one of devices 119A-119C) to determine its final destination. Once a package 220 is assigned to a particular route and/or sub-route, workers and/or machines can transport the package 220 to be shipped. In exemplary FIG. 2 , camp area 215 includes a truck 222 , a car 226 , and couriers 224A and 224B. In some embodiments, courier 224A may drive truck 222, courier 224A is a full-time employee who delivers packages for FC 200, and truck owns or leases FC 200. or owned, leased, or operated by the same company that operates it. In some embodiments, delivery man 224B may drive car 226, which delivery man 224B is a "flex" or non-time worker who makes deliveries on an as-needed (eg, seasonal) basis. Car 226 may be owned, leased or operated by delivery man 224B.

3A shows an exemplary pictographic representation of an intake sub-system 300 . The intake sub-system 300 may be designated for initial handling of communications from a source application program interface (API) 302 . The source API 302 may be any one of a number of APIs specifically configured for use by customers, delivery men, managers, and/or vendors. Source API 302 is a computing device having a processor, memory configuration, and/or communication configuration such as a mobile device, desktop computer, adapter, controller, server, or any other device capable of sending and/or receiving API communications. can be implemented in In some embodiments, intake sub-system 300 and/or a configuration of intake sub-system 300 is communicatively coupled to another sub-system (eg, as shown in FIGS. 3B-3D ). It can be.

Intake sub-system 300 may also include multiple endpoint APIs 304 to which source APIs 302 may be communicatively coupled. In some embodiments, endpoint API 304 may be only one endpoint API. Endpoint API 304 may include a plurality of controllers, adapters, and/or other computing devices that may be managed by an API provider (not shown). For example, endpoint API 304 may be implemented by a combination of controllers, such as controller 306a, controller 306b, controller 306c, controller 306d, and/or controller 306e. In some embodiments, a controller may be designated to handle actions for a particular entity (eg, merchant). The controller may be a hardware device or software program capable of managing data flow between different entities (eg, between the source API 302 and the data aggregator 312). For example, the controller may be, without limitation, a flash controller, an application delivery controller, a main area controller, a baseboard management controller, and/or a session boundary controller. In some embodiments, communication from source API 302 may be directed to a specific endpoint API or controller based on the source associated with the communication. For example, the API provider receives communications from the source API 302 (e.g., message identifier, internet protocol (IP) address, media access control (MAC) address, communication format , and/or other unique identifier) to determine the source and/or type of communication. Based on the identified communication source and/or communication type, the API provider can direct the communication to a particular controller that can be configured for communication with a particular source and/or type. As a further example, an API provider may determine that a communication from a source API 302 has a consumer device as its communication source and a return request as its communication type, and has the source and/or type of communication received. It may direct the communication to an endpoint API 304 (eg, controller 306b), which may be configured to handle the communication (eg, configured for return request communication).

The intake sub-system 300 can also verify communications from the source API 302 and can include a verifier 308 that can be communicatively coupled to the endpoint API 304 . Validator 308 may reside inside Endpoint API 304 (eg, as part of a controller), or may exist as a separate component such as a server to which Endpoint API 304 may connect. The verifier 308 may include various components (eg, modules, devices, processors, etc.) configured to perform a verification process (eg, a process of verifying communications received from the source API 302). . For example, the verifier 308 may include a verifier call, a verification preprocessor (eg, to reformat data from the communication), a verifier processor (eg, to perform verification operations on the data), a verifier post-processor (e.g., to reformatt the verified data into a format interpretable by another entity, such as rules engine 362 of FIG. 3C), a verification management unit, and/or (to send messages to other sub-systems) may include message publishers).

Intake sub-system 300 may also include an exception handler 310 to which validator 308 may be communicatively coupled. Exception handler 310 may be part of validator 308 or may be a separate device or component, such as a server or mobile device. In some embodiments, verifier 308 may direct the communication to exception handler 310 based on a verification result of the communication that may have been determined by verifier 308 . For example, if the communication does not conform to at least one rule or algorithm implemented by the verifier 308, the verifier may direct the communication to the exception handler 310. In some embodiments, exception handler 310 reformats, splits, parses, tags, and/or otherwise reconstructs information from the communication based on at least one rule or algorithm not met by the communication. or transmit (eg, issue an alert to an administrator device). Exception handler 310 may be communicatively coupled to data aggregator 312 and/or logging and tracking module 314 .

Intake sub-system 300 also includes a data aggregator (which can aggregate data from different sources, such as endpoint API 304, exception handler 310, and/or logging and tracking module 314). 312) may be included. Data aggregator 312 may include components of sub-system 300 and devices and/or components of other systems including sub-systems (325 in FIG. 3B, 355 in FIG. 3C, and 375 in FIG. 3D), as well as It may be communicatively coupled with any device and/or configuration of sub-system 300 . Data aggregator 312 may be part of a device with another purpose (eg, verifier 308 ), or it may be a separate device or component, such as a server or mobile device. In some embodiments, data aggregator 312 performs a data aggregation process (e.g., a process of aggregating and/or analyzing data from sources such as source API 302 and/or exception handler 310). It may include various components (eg, modules, devices, processors, etc.) configured to do so. For example, data aggregator 312 may include a data caching component, a data aggregation component, a data transformation component, a data mapping component, and/or a service router.

Intake sub-system 300 may also include a logging and tracking module 314 that may log and/or track data associated with a communication (eg, communication from API source 302 ). Recording and tracking module 314 may be part of a device with another purpose (eg, data aggregator 312 ), or may be a separate device or component, such as a server or mobile device. Recording and tracking module 314 includes various components configured to perform data ingestion processes (e.g., processes that track and/or record data from sources such as source API 302 and/or exception handler 310). (eg, modules, devices, processors, etc.). For example, the logging and tracking module 314 may include a tracker 316 and/or a tracking analyzer 318 .

Tracker 316 may function to track data, such as data associated with communications from API source 302, verifier 308, and the like. In some embodiments, tracker 316 may be configured to append tracking identifiers and/or span identifiers to data associated with communications. In some embodiments, tracker 316 defines where to transmit trace and/or record data, a threshold number of times to keep trace and/or record, data format, specific combination of identifiers to transmit, and/or specific library to trace. can maintain definitions (eg, user-defined, machine-defined, and/or combinations of user-defined and machine-defined) for recording and tracking, such as In some embodiments, tracker 316 may implement aspects of a feature provider such as Spring Cloud Sleuth.

Trace analyzer 318 may perform functions to analyze data such as trace data and/or historical data that may be associated with communications from a device (eg, a device implementing source API 302 ). For example, tracking analyzer 318 may provide timing data (e.g., time at which an exception occurred, frequency of exceptions, etc.), tags, rule failure data, rule satisfaction data, device identifiers, message identifiers, and/or source APIs ( 302) can be collected. In some embodiments, trace analyzer 318 may provide visual representations of trace and/or log data (eg, charts of filterable data, line diagrams, recommendations generated by statistical and/or machine learning algorithms, etc.). ) can be created. In some embodiments, trace analyzer 318 may implement aspects of a function provider such as Zipkin.

3B shows an exemplary pictographic representation of output sub-system 325 . Output sub-system 325 may be designated for processing the output of workflow sub-system 375 of FIG. 3D. The output sub-system 325 forwards the processed output to the external data source 370 of FIG. 3C, using the logging and tracking module 314 of FIG. You can pass processed output to be logged and/or tracked. The output sub-system 325 may be specifically configured for use by customers, couriers, managers, and/or vendors. Output sub-system 325 may be implemented in a computing device having a processor, memory configuration, and/or communication configuration. In some embodiments, output sub-system 325 and/or components of output sub-system 325 may be communicatively coupled to other sub-systems (eg, as shown in FIGS. 3A-3D ). can

The output sub-system 325 can include a number of Creturns Domains modules 327 that can be communicatively coupled to the workflow sub-system 375 of FIG. 3D. In some embodiments, Creturns Domains module 327 may include various services 329a-d. Examples of services as shown in FIG. 3B may include cancellation service 329a, return service 329b, exchange service 329c, and/or concession service 329d. Each service 329a-d may be responsible for processing output from a respective workflow task in workflow sub-system 375 of FIG. 3D. For example, cancellation process workflow 383a of FIG. 3D may pass output to cancellation service 329a, while return process workflow 383b may pass output to return service 329b. The architecture of Creturns Domains module 327 can be modified to add additional services as needed.

The Creturns Domains module 327 records and tracks using the log and track module 314 and/or the external service proxy module 331 of FIG. 3A and forwards the processed information to the external data source 370 of FIG. 3C. can Information passed to the external data source 370 is stored as described in the section with reference to FIG. 3C. The information passed to the recording and tracking module 314 is recorded and processed as described above in reference to FIG. 3A.

The external service proxy module 331 is part of the output sub-system 325 and can receive processed output from the Creturns Domains module 327 for further direction to the appropriate external service 339a. The output sub-system 325 can use the external service proxy module 331 to repeatedly connect the same service without consuming the time and computing resources required to initialize the service proxy more than once. The external service proxy module 331 may be implemented as a software or hardware system between the Creturns Domains module 327 and the external service 339a. External service proxy module 331 may reside on the same machine as output sub-system 325 or on a separate server. The external service proxy module 331 may be specially configured for use by customers, administrators, and/or vendors. The external service proxy module 331 may be implemented in a computing device having a processor, memory configuration, and/or communication configuration.

The external service proxy module 331 can also receive data directly from the Crenturn workflow starter 381 of FIG. 3D and can be communicatively coupled to the workflow sub-system 375 of FIG. 3D external service tasks. A portion 333 may be included. The external service working unit 333 may exist within the external service proxy module 331 or may exist as a separate component such as a server to which the external service proxy module 331 may be connected. The external service operation unit 333 may include various components (eg, modules, devices, processors, etc.) configured to perform output processing. For example, the external service operation unit 333 may process data not processed by the Crenturns Domains module 327.

In addition, the external service proxy module 331 may include an external API request unit 335 to which the external service proxy module 331 can be communicatively coupled. The external API requester 335 may be part of the external service proxy module 331 or may be a separate device or configuration such as a server or a virtual instance. In some embodiments, the external service proxy module 331 may have direct communication to the external API requester 335 based on which of the external services 339a-e the delivery of output is requested to, such that The external service may be one determined by Creturns Domains module 327 or external service operation unit 333 . For example, when an external service requests an API for communication, the external API requester 335 may request appropriate API information to establish a connection with the requested external service. In some embodiments, the external API requester 335 reformats, splits, parses, tags, and/or otherwise reconstructs or reorganizes information from the communication based on at least one rule or algorithm used by the external service. can transmit

In addition, the external service proxy module 331 may include a production unit 337 to which the external service operation unit 333 is communicatively coupled. Production unit 337 may be part of external service proxy module 331 or may be a separate device or component such as a server or virtual instance. Production unit 337 can be used to publish messages to topics. A topic can be divided into multiple partitions containing messages. Each message within a partition is assigned and identified by its unique offset. Since the message itself contains information about which topics and partitions to publish to, data can be published to different topics using the same producer. In some embodiments, production unit 337 may be implemented using Kafka.

The external service proxy module 331 may forward the processed information to the logging and tracking module 314 of FIG. 3A and/or external services 339a-e. The information passed to the recording and tracking module 314 is recorded and processed as described above in reference to FIG. 3A. External services 339a-e initiate activities based on requests. Examples of services as shown in FIG. 3B may include order service 339a, fulfillment service 339b, delivery service 339c, benefit service 339d, and/or ticket service 339e. Each service 329a-d may be responsible for a specific operation. For example, in an event, workflow sub-system 375 of FIG. 3D may initiate multiple external services, passing outputs to exchange service 329c for processing. The exchange of an item is to order a new item (the order command is to buy the item from the supplier, tell the picker to have the item ready, buy the item online, go to a 3rd party store and pick it up) , or other commands directed to obtaining the item) output to order service 339a, output to shipping service 339c to generate a return shipping slip, and/or process the returned item. output to the fulfillment service 339b to do so. The architecture of output sub-system 325 can be modified to add additional external services as needed.

3C is a pictographic representation 355 of an example control sub-system 350, an example return eventstore 361, an example rules engine 362, and an example external data source 370, in accordance with the disclosed implementations. ).

Control sub-system 350 may be configured to create, update, maintain, and/or manage data used by various components of the system (300 in FIG. 3A, 325 in FIG. 3B, and 375 in FIG. 3D). . For example, control sub-system 350 may include parameters for managing returns by customers (eg, rules for accepting and rejecting returns by customers), and workflows for processing returns. parameters, and/or to create, update, and/or modify parameters for storing specific return events.

As shown in FIG. 3C , the control sub-system 350 may include a rule management module 351 , an event management module 352 , and a workflow management module 353 .

The rule management module 351 may be configured to manage rules for handling returns by customers. For example, the rule management module 351 may be configured to create and/or modify a rule for rejecting a return request by a customer. By way of example, the rule management module 351 may be configured based on various parameters including, for example, data on the customer's previous return(s), the monetary amount involved in the return request, the type of goods to be returned, and the like. and/or create and/or modify rules for rejecting returns requests by customers. For example, if a customer has returned an empty (or partially empty) box for return within a pre-determined number of days in the past (eg, 180 days), this may indicate that the customer was attempting to cheat the system and rule The management module 351 may generate a rule for rejecting a customer's return request.

In some embodiments, rule management module 351 may be configured to create and/or modify rules based on input by a user of control sub-system 350 . For example, the rule management module 351 may receive input from the user for modifying one or more parameters of a rule for verifying a return request and modifying the parameter(s) of the rule accordingly.

The event management module 352 may be configured to create, modify, and/or manage events stored in the returned event store 361 . For example, the event management module 352 may generate a series of events for a return request initiated by a customer or system and store the events in the return event store 361 . As an example, a customer may initiate return of an order via a user device associated with the customer. The event management module 352 may generate an event receiving a return request and store the event in the return event store 361 . In some embodiments, events may include information about returns, customers, and orders associated with returns. For example, the event management module 352 may generate a first event for a return requested by the customer, which may include information on the return request, a timestamp at which the return request was received, information about the customer, or other information. similar ones, or combinations thereof. The event management module 352 may generate a second event when one or more items to be returned are received from the customer, which includes information about the receipt of the item(s) (eg, quantity, status, etc.), item Receipt timestamp of (s), and the like. Also, the event management module 352 may store the first and second events in the return event store 361 as a series of events for return.

In some embodiments, return eventstore 361 may include, for example, an Oracle™ database, Sybase™ database, or other relational database or non-relational database such as Hadoop™ sequence files, HBase™, or Cassandra™. there is. The return eventstore 361 may include a NoSQL database such as HBase, MongoDB™ or Cassandra™. Optionally, database 320 may include relational databases such as Oracle, MySQL and Microsoft SQL Server. In some embodiments, return eventstore 361 may take the form of a server, general purpose computer, mainframe computer, or any combination of these configurations.

The workflow management module 353 may create, modify, and/or manage workflows used by various components of the system (300 in FIG. 3A, 325 in FIG. 3B, and 375 in FIG. 3D). For example, workflow management module 353 may include cancellation process 383a, return process 383b, exchange process 383c, shipment tracking utilized by workflow sub-system 375 (shown in FIG. 3D). 383d, collection process 383e, refund process 383f, and withdrawal process 383g.

In some embodiments, control sub-system 350 may be configured to create, modify, and/or manage services used by Creturns Domains module 327 (shown in FIG. 3B ). For example, control sub-system 350 may be configured to create, modify, and/or manage cancellation service 329a, return service 329b, exchange service 329c, and/or concession service 329d. can Creturns Domains module 327 can obtain one or more services from control sub-system 350 .

Rules engine 362 is configured to obtain rules for processing returns from control sub-system 350, and to store and/or manage rules for other components of workflow sub-system 375 of FIG. 3D. can be configured. For example, workflow sub-system 375 of FIG. 3D can be configured to obtain rules for validating return requests from rules engine 362 . In some embodiments, rules engine 362 may include a rules database 363 for storing rules for managing and/or processing returns.

The external data source 370 may be configured to store data for various configurations of the system including subsystems (300 in FIG. 3A, 325 in FIG. 3B, and 375 in FIG. 3D). For example, the external data source 370 may control sub-system 350 including, for example, cancellation service 329a, return service 329b, exchange service 329c, and/or concession service 329d. ) can store various services created and/or updated by Creturns Domains module 327 can obtain one or more services from an external data source 370 .

As another example, the external data source 370 may include an eventstore 371 configured to store data about events (eg, return events). In some embodiments, event store 371 may include write database 372 configured to write data in response to a write command. The event store may include one or more read databases 373 (eg, read database 373A, read database 373B, etc.) configured to read data only in response to query commands. In some embodiments, the read database 373 may include the same data as the data included in the write database 372 . For example, if data stored in the write database 372 is updated in response to a write command, corresponding data in the read database 373 is adjusted so that the write database 373 and the read database 373 contain the same data. can be updated In some embodiments, external data source 370 may include an admin database 374 configured to store administration data for control sub-system 350 .

In some embodiments, event store 371 and/or management database 374 may be, for example, an Oracle™ database, Sybase™ database, or other relational database or Hadoop™ sequence file, HBase™, or Cassandra™. Can include non-relational databases. Event store 371 and/or management database 374 may include a NoSQL database such as HBase, MongoDB™ or Cassandra™. Optionally, database 320 may include relational databases such as Oracle, MySQL and Microsoft SQL Server. In some embodiments, event store 371 and/or management database 374 may take the form of a server, general purpose computer, mainframe computer, or any combination of these configurations.

3D shows an exemplary pictographic representation of workflow sub-system 375. Workflow sub-system 375 may be designated for processing the output of intake sub-system 300 . Workflow sub-system 375 can pass the verifier 308 output to output sub-system 325 . Workflow sub-system 375 may be specifically configured for use by customers, delivery people, managers, and/or vendors. Workflow sub-system 375 may be implemented in a computing device having a processor, memory configuration, and/or communication configuration. In some embodiments, workflow sub-system 375 and/or components of workflow sub-system 375 are communicatively coupled to other sub-systems (eg, as shown in FIGS. 3A-3D ). It can be.

Workflow sub-system 375 may include framework module 377 . Framework module 377 may utilize Spring WebFlux or similar technology. Framework module 377 can provide a non-blocking web stack that handles concurrency at the scale of fewer threads and fewer hardware resources. The framework module 377 may include various programming modules. Examples of modules as shown in FIG. 3D may include a return module 379a, an exchange module 379b, and a cancellation module 379c. Modules 379a-c may include processing logic for retail, third party, and ticket offers. Modules 379a-c may also include APIs for communicating with sub-systems that manage the respective data.

Workflow sub-system 375 may also include workflow starter 381 , which may be communicatively coupled to framework module 377 . Workflow starter 381 can include a list of processes 383a-g that can initiate a workflow based on input received from framework module 377 . Examples of processes as shown in FIG. 3D include a cancellation process 383a (including instructions for initiating a workflow initiated by a cancellation of an order by a customer, supplier, or other order handler), a return process 383b (including instructions for initiating a workflow initiated by all or part orders returned by a customer, supplier, or other order handler), exchange process 383c (initiated by a customer, supplier, or other order handler) includes instructions for initiating a workflow initiated by the exchange of all or part orders), shipment tracking 383d (initiated by a request by a customer, supplier, or other order handler to track the delivery status of all or part orders) collection process 383e (including instructions for initiating a workflow initiated by a request to track information on all or part of an order by a customer, supplier, or other order handler); ), a refund process 383f (including instructions for initiating a workflow initiated by a refund request for all or part of an order initiated by a customer, supplier, or other order handler), and a withdrawal process 383g (including instructions for starting a workflow initiated by the withdrawal of all or part of an order initiated by a customer, supplier, or other order handler).

Additionally, each programming module 379a-c of the framework module 377 can initiate multiple processes 383a-g. For example, cancellation module 379c can initiate shipment tracking process 383d to determine if the canceled item has been shipped or is still in the delivery person's possession. The same cancellation module 379c can also initiate a refund process 383f to refund the customer.

Various combinations may be programmed and configured specifically for use by customers, delivery men, managers, and/or vendors. Workflow starter 381 may be implemented in a computing device having a processor, memory configuration, and/or communication configuration. In some embodiments, workflow starter 381 and/or components of workflow starter 381 are communicably communicable to other portions of workflow sub-system 375 (eg, as shown in FIG. 3D ). can be combined Additionally, the architecture of workflow sub-system 375 is modified to add additional processing and program modules as needed.

Workflow sub-system 375 may also include a workflow service module 385 that may be communicatively coupled with workflow starter 381 and output sub-system 325 . Workflow services module 385 may be designated for workflow control and design. The workflow service module 385 may include a Creturn workflow service module 387 and a workflow orchestration module 391 . Workflow services module 385 can provide output for processing by output sub-system 325 .

The Creturn workflow service module 387 can include a number of sub-modules 389a-b that can control the workflow based on input received from the workflow starter 381 . An example of a process as shown in FIG. 3D is a retail returns sub-module 389a that allows design and/or control of workflows for returns of retail items and design and/or workflows for returns of third party items. or a third party returns sub-module 389b allowing control. The architecture of the Creturn workflow service module 387 can be modified to add additional sub-modules as needed. Workflows within the Creturn Workflow Services module 387 may be controlled and/or designed by customers, couriers, managers, and/or vendors. Creturn workflow service module 387 may be implemented in a computing device having a processor, memory configuration, and/or communication configuration and may be communicatively coupled to other portions of workflow sub-system 375 .

Workflow orchestration module 391 may include a set of workflow controls that may be accessed by customers, delivery people, managers, and/or vendors. The workflow orchestration module 391 may be implemented using a business process management (BPM) engine and a supporting framework, examples of which may be Activiti and Spring Boot/Docker. The Workflow Orchestration Module 391 engine has a core goal of taking process definitions consisting of human tasks and service calls and executing them in a specific order, and various APIs for starting, managing, and querying data about process instances for the definitions. can be disclosed. Workflow orchestration module 391 may be implemented in a computing device having a processor, memory configuration, and/or communication configuration. Workflow orchestration module 391 may be communicatively coupled to other portions of workflow sub-system 375 .

4 shows an example pictogram of a network environment 400 for return processing using the presently disclosed embodiment. For clarity and further explanation, only a sub-set of the other systems, sub-systems, and modules shown in FIGS. 3A-3D are shown in FIG. 4 , but other elements of FIGS. there is. Moreover, the configurations and functions of the elements disclosed below may be combined with the configurations and functions of the elements corresponding to FIGS. 3A-3D.

In some embodiments, source API 302 may include any number of APIs configured to send electronic requests for return. Each of the source APIs 302 may reside in a communication device, such as a customer's mobile device 102A, or an internal customer service system that an operator can use to passively register return requests from a customer. For example, using such a device, the source API 302 is a mobile application that is installed on the customer's mobile device and forwards API calls to the endpoint API 304, and is accessed from the customer's computer to forward similar API calls. It may include a web page, an application that operates on a customer service agent's computer and manually inputs a return request, and the like.

Endpoint API 304 may receive API calls from source API 302 and route them to appropriate systems, sub-systems, and/or modules in network environment 400 . In some embodiments, the endpoint API is a controller described above to further handle received API calls and adapt the communication protocol (eg, JAVA, HTML, CSS, or other programming languages) of the network environment 400. (306a-e) can be used.

In some embodiments, one of the entities receiving routed API calls may be the verifier 308 . Verifier 308 may be configured to check data included in routed API calls to ensure that all required information is present and complies with respective data types and formats, for example.

In some embodiments, validated API calls may be sent to workflow service module 385 via, for example, framework module 377 and workflow starter 381 . Workflow service module 385 is configured to process verified API calls based on different rules initiated by different processes of workflow starter 381 (eg, return process 383b or refund process 383f). and take various actions as appropriate for each request represented by the API call.

Consistent with the embodiments disclosed herein, some of the rules may be used to identify whether a return request call is suitable for a streamlined process. Identification may be based on considering the data included in each API call as a whole, in which the values of the different parameters of the API call are analyzed in combination with each other. For example, the workflow service module 385 may provide a customer specified code, type of item to be returned, price of the item to be returned, past returns of the customer, location of the seller, or other aspects of the item to be returned and the corresponding order. One or more of them can be analyzed.

In some embodiments, rules used by workflow service module 385 may be stored in rule management module 351 . As described above with respect to FIG. 3C , the rule management module 351 may be configured to manage rules for processing a return requested in each return request call. The rule management module 351 may utilize rule engine technology via the rule engine 362, which places rules (or corresponding business logic), such as return conformance criteria or simplified process conformance criteria, into a centralized rule database 363. A centralized storage function can be provided. For example, this may allow rules to be easily changed to quickly meet new customer demand, regulatory changes, and/or competition in the marketplace.

Once a return request call has been processed by the workflow services module 385 (eg, determining whether to accept or reject the return request, or determining whether the return request fits into a streamlined process), the workflow services module 385 A series of additional API calls can be created and sent to signal other systems, sub-systems, or modules to take appropriate actions. For example, when workflow services module 385 determines that the return request call is approved, workflow services module 385 may activate fulfillment service 339b and/or delivery service 339c to activate Creturns Domain The module 327 may make a call to the external service proxy 331 . The process through which an approved return request call goes through is described below with respect to FIG. 5 .

5 is a flow diagram of an exemplary computerized process 500 for return processing using presently disclosed embodiments. Although process 500 is described as applied to return processing, this use is merely illustrative and process 500 may be modified to employ other processes to reduce network load and improve scalability. Process 500 may be performed with any system, network of systems, server, etc. that is responsible for return processing, such as the systems described above with respect to FIGS. 3A-3D and FIG. 4 . Process 500 is described below with reference to network environment 400 of FIG. 4 as well as sub-systems of FIGS. 3A-3D , but any other component of a system, sub-system, or module to perform process 500. this can be used

Process 500 depicts two exemplary processes for reviewing and executing return requests. - that is, the regular process represented by steps 501-506 to improve the accuracy of return management (e.g. receipt of requests and receipt of returned items) and steps 501-503, 507 to improve review and execution speed of returns. and 508, a simplified process is described. In some embodiments, both processes of process 500 may be performed by the systems, sub-systems, and modules shown in FIGS. 3A-3D , a sub-set of which is also shown in FIG. 4 . Variations of both processes are also within the scope of embodiments of the present disclosure, and process 500 may also include other processes for reviewing and executing return requests.

At step 501, a regular process may be initiated by receiving a return request to return an item from a customer device. In some embodiments, the return request may be a return request call created and sent by the source API 302 . For example, a return request may be created by a customer to return one of the items that the customer previously ordered or received. In some embodiments, endpoint API 304 may route the return request call to the appropriate destination as described above.

At step 502, the verifier 308 may verify the return request call against a system record. For example, the verifier 308 extracts basic information from the return request call, such as customer information, the item identifier of the item to be returned, and the order identifier of the original order associated with that item, and confirms that the customer is the person who actually ordered the item and that the item Information may be queried in the FO system 113 to verify that the order has actually been included in the correct quantity. In some embodiments, verifier 308 may use the extracted information to determine whether an item is eligible for return. These rules may be some of the rules stored in the rule management module 351 described above.

At step 503, the workflow service module 385 may analyze the return request call to determine its suitability for the simplified process. In the following, step 503 is described in more detail in the context of a simplified process. In some embodiments where process 500 includes only a regular process or a simplified process, step 503 may be omitted or substituted to perform another function. In a further embodiment, step 503 may involve various modules such as Creturn Workflow Services module 387, Retail Returns sub-module 389a, Third Party Returns sub-module 389b, and Workflow Orchestration module 391 described above. may include determining whether or not to approve a return request using

At step 504, Workflow Services module 385 makes a series of API calls, as described above, to Creturns domain module 327, external service proxy module 331, fulfillment service 339b, and delivery service 339c. ) to other systems, sub-systems or modules. In some embodiments, workflow service module 385 may make one or more API calls to request the retrieval of an item to be returned, which may generate, for example, a return shipping label or pick an item from a customer. up) may include dispatching a courier. Additionally or alternatively, the one or more API calls may also cause an autonomous system, such as an autonomous robot, vehicle, or drone, to travel to a designated customer's address and retrieve the item in response to the return request call.

In a further embodiment, step 504 may also include receiving the returned item and restocking it to a fulfillment center, which may be performed using an autonomous robot, vehicle, or the like. For example, step 504 captures the item identifier (eg, using a camera, scanner, RFID sensor, etc.) when the returned item arrives at the fulfillment center, and external data to record the item's retrieval or arrival. This may include updating the data record of the source 370.

As discussed above with respect to FIG. 3B , retrieval and restocking of items may involve a complex network of modules each communicating using API calls. For example, the return service 329b triggers a series of subsequent calls to downstream modules (e.g., external service proxy 331 or elements of services 339a-e), a workflow service module. 385, each of which relates to the physical movement of the items from the customer address to various locations within the fulfillment center (e.g., FC 200) as the items are retrieved and restocked. there is.

At step 505, once the returned item is received at the fulfillment center (e.g., FC 200), the output sub-system 325 makes another set of API calls to request a refund for the price of the returned item. can create In some embodiments, the workflow service module 385 may generate and send a set of API calls for refund to a payment management system (not shown) for communication with the financial institution and eventual release of the payment. The API call for a refund may also prompt the external data source 370 to update the data record for the customer who requested the return.

Further, at operation 506, the output sub-system 325 may generate and transmit a notification (eg, text message, in-app push notification, email, etc.) to a customer device associated with the customer requesting a return. This notification may be sent in response to the completion of an API call for a refund. In some embodiments, the customer device may be the device that initially transmits the return request call in step 501 above. Additionally or alternatively, the customer device may be another device authenticated using the customer's login credentials.

Although the exchange of API calls between networks of different systems, sub-systems, and modules may seem complex, such exchanges may allow different functional units (ie sub-systems or modules) to specialize in specific tasks. This can improve efficiency and reduce error rates compared to the traditional process of return management. In some embodiments, this compartmentalized treatment of different tasks may enable modular implementation of each sub-system or module, which also improves flexibility when any sub-system or module fails, allowing the network You can make other parts of it work on their own.

On the other hand, the streamlined process can improve return management speed by omitting some of the steps performed in the regular process, such as retrieving and restocking items for return. While a formal process can improve the efficiency and correctness of return management, each API call exchanged between different sub-systems and modules in response to each return request call as described above affects the network of systems, sub-systems and modules. put a load on The load, though small, can quickly accumulate throttle and limit or overwhelm the network as the number of return request calls increases.

For example, as the system processes and tracks return request calls, 10 or more API calls per return request may be made to delivery service 339c throughout the day. Each of the 10 or more API calls may also trigger a series of subsequent calls in the other network systems described above with respect to FIG. 1A (eg, SAT system 101), which adds network load. In general, step 504 may account for the majority of the resources spent processing returns through process 500 .

The streamlined process eliminates the need for these API calls for a subset of return request calls, which reduces network load. While the savings realized by the streamlined process with respect to individual return call requests may be negligible, the savings realized between hundreds of thousands or millions of users and their requests can accumulate to significant benefits that improve the scalability of the network. In other words, the reduction in network resources resulting from handling return request calls through a streamlined process can ensure low latency and optimal network utilization even as the number of users and their requests grow exponentially. As a result, these savings can contribute to lower operating costs in terms of maintaining and operating the network.

In addition, the streamlined process can also reduce operational costs in terms of actual man-hours and physical resources required for regular processes. For example, if step 504 involves retrieving a returned item from a customer, an operator must be sent to the customer's address, obtain the returned item, and return the returned item. Multiple visits may be necessary if the customer is away and the worker needs to be sent back. For another example, inspecting and restocking returned items is also costly, which can further complicate regular procedures if returned items are damaged or must be disposed of according to environmental regulations. Thus, for a subset of return requests suitable for a streamlined process, a streamlined process derives both technical and business advantages over a regular process.

Returning to the simplified process represented by steps 501-503, 507, and 508, the process can share steps 501-503 with a regular process. In such an embodiment, all return request calls may go through steps 501 and 502 before being divided into either the regular process described above or the simplified process described below.

At step 503, the workflow service module 385 may analyze the return request call to determine suitability for the simplified process. This determination may be based on a set of rules stored in the rule management module 351 . In some embodiments, rules may correspond to one or more different scenarios in which a return request call fails. Exemplary scenarios are described below, and other scenarios or variations thereof are within the scope of the disclosed embodiments.

As a starting point, some of the returns request calls may have been received before the order was shipped to the customer. As such, the workflow service module 385 can be configured to verify that the order has been shipped. The workflow service module 385 can accomplish this by making an API call to the FO system 113 with the corresponding order identifier and receiving the status of the order. Workflow service module 385 may cancel the order and create a refund request as discussed above if the order has not yet been shipped, or otherwise determine whether a return request call fits into the streamlined process. can proceed

In some embodiments, one or more rules may determine eligibility based on a customer specified code indicating the reason for requesting a return. For example, the customer-specified code may be specified when a customer submits a return request through a mobile application or website, and may be included as a parameter in a corresponding return request call. The customer specific code may include any pre-determined set of alphanumeric text strings related to different scenarios. For example, possible scenarios could include change of heart, wrong item, shipping damage, inconsistency with item description, missing item, etc.

In some embodiments, a return request call containing a customer-specified code associated with a missing item is suitable for a streamlined process, since the customer cannot physically return the item if the item is missing in the first place (eg, lost or undelivered). can be set to In some embodiments, workflow module 385 may also compare item identifiers corresponding to items to be returned with a list of items suitable for the streamlined process. Optionally or additionally, other code associated with different scenarios may also be configured to suit the streamlined process as determined by required business practices.

In addition, the workflow service module 385 may query records associated with the customer requesting a return to determine whether the customer has fraudulently selected the reason code for the missing item. This determination may be made by a fraud detection system (not shown) that keeps a detailed log of each customer's purchase and return activity. Fraud detection systems can then analyze the logs with machine learning algorithms to identify suspicious requests. For example, logs may include the type of item purchased by the customer, the price of the item, the sub-set of items returned, the price and condition of items returned, or any other information directly or indirectly contained in the customer's return request. can be traced. Additionally or alternatively, the workflow service module 385 may still set a return request call containing a customer specified code associated with the missing item as ineligible if the item's purchase price is greater than a predetermined threshold. This allows workflow services module 385 to more thoroughly review return request calls while they go through regular processing and to identify any fraudulent requests.

Returning to step 503, another set of rules may be included in the return request call to determine eligibility based on information indicating that the customer has already shipped the item to the fulfillment center. For example, the information may include one of the customer specified codes described above and/or a tracking number for return shipments. In such a case, the workflow services module 385 may determine that it does not need to generate a retrieval request as described above with respect to step 504, and may determine that the return request call is suitable for a simplified process. Workflow service module 385 may also generate and send API calls to update records associated with specific items to be returned by a customer to include information about the customer's own return shipment. In some embodiments, the workflow service module 385 may proceed to create a refund request and send a notification to the customer device in the manner described above with respect to steps 507 and 508 .

In a further embodiment, another set of rules may determine suitability for the streamlined process based on the type of item to be returned. For example, eligible types may include perishable items that do not arrive at a fulfillment center in resaleable condition, or items purchased from foreign sources that may incur relatively high return shipping costs. In some embodiments, workflow service module 385 sends an electronic query to a connected database (eg, external data source 370) with the item identifier included in the return request call and receives parameters for the item type. By doing so, you can determine the item type.

The linked database may be configured to maintain a list of item identifiers with recommended storage temperatures and to respond to electronic queries with a suitability decision based on those storage temperatures. For example, an item with a recommended storage temperature below its freezing point may be considered unsuitable because it is more likely to break during transit. In a further embodiment, the list of item identifiers in the connected database may specify whether some of the items are sold by foreign entities. In some cases, it is better not to retrieve an item because the cost of retrieving the item and shipping the item back to the foreign company may be too high. As such, if the purchase price of an item is below a pre-determined threshold, the connected database may determine that such item should be eligible for a streamlined process (thus refunding the purchase price without recall of the item).

If workflow service module 385 determines that the type of item to be returned matches one of the pre-determined set of item types, workflow service module 385 may further determine that the return request call is suitable for the streamlined process. there is. In some embodiments, this may be because the returned item may not be resellable or profitable and there is no need to create a retrieval request as described above with respect to step 504 . In some embodiments, the workflow service module 385 may proceed again by generating a refund request and sending a notification to the customer device in the manner described above with respect to steps 507 and 508 .

In some embodiments, a customer's record of requesting a return consistent with the streamlined process may be updated to reflect that the customer is eligible for a non-return refund of the item. These records may later be used by a fraud detection system (not shown) to analyze and identify fraudulent return request calls that appear to be eligible for other non-return refunds.

If the workflow services module 385 determines at step 507 that the return request call is suitable for a simplified process, the workflow services module 385 may proceed with the refund request as described above with respect to step 505 . However, in contrast to step 505, where a refund request is issued in response to receipt of the returned item, workflow service module 385 may generate an API call for a refund request when it determines that the return request call is suitable for a streamlined process. can

Optionally or additionally, workflow service module 385 may perform additional checks to identify fraudulent return requests before issuing a refund. The workflow service module 385 may send an API call to the fraud detection system along with the corresponding return request call information and information about the customer, and in response, the fraud detection system returns a determination as to whether the return request call is fraudulent. can do. A positive decision may cause the workflow service module 385 to reject the refund request and process the return request call under the regular process beginning at step 504 . In some embodiments, the workflow service module 385 may also notify the delivery service 339c to specify that no items are to be returned, and in step 508 notify the customer device, as described above with respect to step 506. can transmit.

6 shows an exemplary flow diagram of a computerized process 600 for processing a refund. Process 600 may be performed in conjunction with all refund requests generated by the system described above, including refund requests generated in the regular process of step 505 and refund requests generated in the streamlined process of step 507, but It is not limited to this. Process 600 may be performed with any system, network of systems, server, etc. responsible for processing refunds, such as the system described above with respect to FIGS. 3A-3D and FIG. 4 . Although process 600 is described below with reference to the sub-systems of FIGS. 3A-3D as well as the network environment 400 of FIG. can be used

In step 601, workflow starter 381 may initiate a refund process by receiving a refund request to refund the purchase price of one or more items. The refund request may be in the form of an API call created and sent by the workflow service module 385 . In some embodiments, operation 601 may further include adding a refund request to a refund request queue via refund process 383f.

In operation 602, the workflow service module 385 may send a request to the benefit service 339d with information to identify the order and receive the benefit data to calculate an appropriate refund amount. Benefit data may include information on discounts and promotions received by the corresponding customer at the time of purchase. Discounts and promotions may have been offered by various entities such as vendors, online retailers, online marketplace platforms, payment processors, banks, and the like. In some embodiments, workflow service module 385 may transmit this data to a payment processing module (not shown) via order service 339a.

At step 603, the payment processing module may update the order status and payment status of the order, which may include updating corresponding records in one or more network databases to reflect the total payment amount and items returned after a refund. .

In step 604, the payment processing module may check the type of payment previously made by the customer by retrieving corresponding information while updating the order status. In some embodiments, the payment processing module identifies the entity with which it should be contacted to reverse a previous transaction (eg, to reverse a cashback or membership rewards transaction) and benefit data and data to determine the amount that should be returned to the customer. Associated ordering information is available.

At step 605, the payment processing module may send a set of API calls containing individual refund requests to the appropriate payment intermediary. A payment intermediary here may include the entity identified in step 604 above as well as a payment processor for the payment method used by the customer.

At step 606, the payment processing module may receive an external refund confirmation from each payment intermediary confirming that the individual refund request has been completed and a refund has been issued (or will be issued after further processing).

When external refund confirmations are received from all payment intermediaries in step 607 , the payment processing module may send the internal refund confirmations back to the workflow service module 385 . In some embodiments, the internal refund confirmation may indicate to workflow service module 385 that a refund has been issued and may proceed with sending a notification to the customer device as described above in operations 506 and 508 .

Although the present disclosure has been shown and described with reference to specific embodiments thereof, it will be understood that the present disclosure may be practiced in other circumstances, without modification. The foregoing description has been presented for purposes of illustration. It is not exhaustive or limited to the exact form or embodiment disclosed. Variations and adjustments will be apparent to those skilled in the art from consideration of the description and practice of the disclosed embodiments. Additionally, although the forms of the disclosed embodiments have been described as being stored in memory, those skilled in the art will understand that these forms can be stored on a secondary storage device, such as a hard disk or CD ROM, or other form of RAM or ROM, USB media, DVD , Blu-ray, or other optical drive media.

Computer programs based on the foregoing description and disclosed methods are well within the skill of the skilled developer. Several programs or program modules can be created using any technology known to those skilled in the art, or designed in connection with existing software. For example, a program section or program module may include the .NET Framework, .NET Compact Framework (and related languages, such as Visual Basic, C, etc.), Java, C++, Objective C, HTML, HTML/AJAX combinations, XML, or Java applets. can be designed in or by embedded HTML.

Moreover, although exemplary embodiments have been described herein, the scope of some or all embodiments is equivalent to elements, variations, omissions, combinations (eg, spanning multiple embodiments), as would be understood by those skilled in the art based on the present disclosure. combinations of shapes), adjustments and/or modifications. The limitations in the claims are intended to be broadly understood based on the language applied within the claims and are not limited to the examples set forth within this specification or during the performance of the application. The examples are intended to be construed on a non-exclusive basis. Additionally, steps of the disclosed methods may be altered in some other way, rearranged steps and/or may include inserting or deleting steps. Therefore, it is intended that the description and examples be considered illustrative only, with the true scope and spirit being indicated by the following claims and their full scope equivalents.

Claims (20)

A computer implemented system for processing returns without receiving items to minimize network load, comprising:
The system,
at least one non-transitory computer readable medium configured to store instructions; and
at least one processor configured to execute the instructions to perform an operation;
The action is
receiving a return API (application programming interface) call requesting return of an unwanted item from a user device;
verifying the returned API call against data records in a networked database;
comparing a parameter associated with the returned item with a reason code included in the return API call;
If the parameters associated with the returned item with respect to the reason code are acceptable:
Sending a refund API call to a payment management system;
updating the data record of the networked database to record a refund; and
transmitting a notification regarding approval of the refund to the user device; and
If the parameter associated with the returned item with respect to the reason code is not acceptable:
generating a retrieval API call requesting retrieval of the returned item;
capturing an item identifier of the returned item upon the retrieval of the returned item;
updating the data record of the networked database to record the number of returned items;
transmitting the collection API call to a payment management system; and
and sending a notification to the user device regarding approval of the recall API call.
The method of claim 1, wherein verifying the return API call comprises:
A computer-implemented system that performs based on one or more system rules stored in a centralized repository.
The method of claim 2, wherein the verifying of the return API call comprises:
and verifying compliance of the return API call to at least one of the system rules.
The method of claim 1, wherein the reason code is
A computer implemented system corresponding to at least one of a predefined set of scenarios.
The method of claim 1, wherein parameters associated with the returned item are:
A computer implemented system indicating whether the returned item satisfies one or more requirements of the reason code.
The method of claim 1, wherein generating the refund API call comprises:
and transmitting the refund API call to a payment management system.
According to claim 1,
The computer implemented system of claim 1, wherein generating the return API call includes generating a return shipping label.
The method of claim 1, wherein generating the refund API call comprises:
The computer implemented system is further responsive to determining that the recall API call is processed.
The method of claim 1, wherein the recovery API call,
A computer implemented system configured to generate a signal for a networked sub-system to retrieve the returned item.
The method of claim 1, wherein the notification for the user device,
A computer implemented system that is a push notification.
A method for a computer implemented method for processing a return without receiving an item to minimize network load, comprising:
receiving a return API call requesting return of an unwanted item from a user device;
verifying the returned API call against data records in a networked database;
comparing a parameter associated with the returned item with a reason code included in the return API call;
If the parameters associated with the returned item with respect to the reason code are acceptable:
Sending a refund API call to a payment management system;
updating the data record of the networked database to record a refund; and
transmitting a notification regarding approval of the refund to the user device; and
If the parameter associated with the returned item with respect to the reason code is not acceptable:
generating a retrieval API call requesting retrieval of the returned item;
capturing an item identifier of the returned item upon the retrieval of the returned item;
updating the data record of the networked database to record the number of returned items;
transmitting the collection API call to a payment management system; and
and transmitting, to the user device, a notification regarding approval of the recall API call.
The method of claim 11, wherein the verifying the refund API call comprises:
A computer implemented method based on one or more system rules stored in a centralized repository.
The method of claim 12, wherein the verifying the refund API call comprises:
and verifying compliance of the return API call to at least one of the system rules.
The method of claim 11, wherein the reason code is
A computer implemented method corresponding to at least one of a set of predefined scenarios.
The method of claim 11, wherein the parameters associated with the returned item are:
A computer implemented method for indicating whether the returned item satisfies one or more necessary conditions of the reason code.
12. The method of claim 11, wherein generating the refund API call comprises:
A computer implemented method comprising transmitting the refund API call to a payment management system.
According to claim 11,
The computer implemented method of claim 1 , wherein generating the return API call includes generating a return shipping label.
12. The method of claim 11, wherein generating the refund API call comprises:
The computer implemented method further responds to determining that the recall API call is processed.
The method of claim 11, wherein the recovery API call,
A computer implemented method configured to generate a signal for a networked sub-system to retrieve the returned item.
A computer implemented system for processing returns without receiving items to minimize network load, comprising:
The system,
at least one non-transitory computer readable medium configured to store instructions; and
at least one processor configured to execute the instructions to perform an operation; including,
The action is
receiving a return API call requesting return of an item returned from a user device;
verifying the returned API call against data records in a networked database;
comparing a category identifier associated with the returned item with a reason code included in the return API call; including,
If the category identifier is acceptable with respect to the reason code:
send a refund API call to the payment management system;
update the data record in the networked database to record a refund;
Sending a notification about the approval of the refund to the user device;
If the category identifier is not acceptable with respect to the reason code:
Create a retrieval API call requesting retrieval of the returned item;
capture an item identifier of the returned item upon the retrieval of the returned item;
update the data record in the networked database to record the number of returned items;
Sending the collection API call to the payment management system;
A computer implemented system for sending a notification to a user device regarding approval of the recall API call.

Images