KR20220071144A - 작업 흐름 편집을 위한 시스템 및 방법 - Google Patents

작업 흐름 편집을 위한 시스템 및 방법 Download PDF

Info

Publication number
KR20220071144A
KR20220071144A KR1020217019560A KR20217019560A KR20220071144A KR 20220071144 A KR20220071144 A KR 20220071144A KR 1020217019560 A KR1020217019560 A KR 1020217019560A KR 20217019560 A KR20217019560 A KR 20217019560A KR 20220071144 A KR20220071144 A KR 20220071144A
Authority
KR
South Korea
Prior art keywords
workflow
blocks
block
operations
return
Prior art date
Application number
KR1020217019560A
Other languages
English (en)
Other versions
KR102548910B1 (ko
Inventor
손재현
Original Assignee
쿠팡 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 쿠팡 주식회사 filed Critical 쿠팡 주식회사
Priority to KR1020237021386A priority Critical patent/KR20230098375A/ko
Publication of KR20220071144A publication Critical patent/KR20220071144A/ko
Application granted granted Critical
Publication of KR102548910B1 publication Critical patent/KR102548910B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0633—Workflow analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
    • G06F3/0481—Interaction techniques based on graphical user interfaces [GUI] based on specific properties of the displayed interaction object or a metaphor-based environment, e.g. interaction with desktop elements like windows or icons, or assisted by a cursor's changing behaviour or appearance
    • G06F3/0482—Interaction with lists of selectable items, e.g. menus
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
    • G06F3/0484—Interaction techniques based on graphical user interfaces [GUI] for the control of specific functions or operations, e.g. selecting or manipulating an object, an image or a displayed text element, setting a parameter value or selecting a range
    • G06F3/04842—Selection of displayed objects or displayed text elements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
    • G06F3/0484—Interaction techniques based on graphical user interfaces [GUI] for the control of specific functions or operations, e.g. selecting or manipulating an object, an image or a displayed text element, setting a parameter value or selecting a range
    • G06F3/04847—Interaction techniques to control parameter settings, e.g. interaction with sliders or dials
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
    • G06F3/0487—Interaction techniques based on graphical user interfaces [GUI] using specific features provided by the input device, e.g. functions controlled by the rotation of a mouse with dual sensing arrangements, or of the nature of the input device, e.g. tap gestures based on pressure sensed by a digitiser
    • G06F3/0488—Interaction techniques based on graphical user interfaces [GUI] using specific features provided by the input device, e.g. functions controlled by the rotation of a mouse with dual sensing arrangements, or of the nature of the input device, e.g. tap gestures based on pressure sensed by a digitiser using a touch-screen or digitiser, e.g. input of commands through traced gestures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0637—Strategic management or analysis, e.g. setting a goal or target of an organisation; Planning actions based on goals; Analysis or evaluation of effectiveness of goals
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/083—Shipping
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/083—Shipping
    • G06Q10/0837—Return transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/087—Inventory or stock management, e.g. order filling, procurement or balancing against orders
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/407—Cancellation of a transaction

Abstract

본 개시에 따른 인스트럭션들을 저장하는 메모리 및 상기 인스트럭션들을 실행하도록 설정된 적어도 하나의 프로세서를 포함하는 작업 흐름 편집을 위한 시스템. 상기 인스트럭션들은 프로세서가, 그래픽 사용자 인터페이스에 기존 작업 흐름을 표시하도록 할 수 있고, 상기 작업 흐름은 복수의 블록들을 포함한다. 사용자로부터 상기 복수의 블록들에 대한 편집이 수신될 수 있고, 편집은 적어도 개별 블록 또는 상기 복수의 블록들 간의 상호 연결에 대한 편집을 포함한다. 또한, 상기 시스템 내에서 기존 작업 흐름을 대체하기 위해 수신된 편집에 기초하여 수정된 작업 흐름이 생성 및 전파될 수 있다. 마지막으로, 그래픽 사용자 인터페이스는 추가 편집을 위해 상기 수정된 작업 흐름을 표시할 수 있다.

Description

작업 흐름 편집을 위한 시스템 및 방법
본 개시는 일반적으로 반환 작업 흐름 편집을 위한 컴퓨터 시스템 및 방법에 관한 것이다. 특히, 본 개시의 실시예는 배송 네트워크와 관련된 작업 흐름을 코드 없이 편집하기 위해 사용이 용이한 그래픽 사용자 인터페이스를 제공하는 것에 대한 창의적이고 독특한 시스템에 관한 것이다.
제품에 대한 소비자 주문을 처리하는 분야에서,　시스템은 개인이 주문한 후에 발생할 수 있는 이슈를 취급하는데 이용된다.　예를 들면,　소비자는 처리 또는 배송에 대한 다수의 특정 단계들 중 어디서든 아이템의 반환,　교환,　또는 취소를 결정할 수 있다.　풀필먼트 서비스(fulfillment services)가 소비자의 요구를 극히 빠르게 충족하도록 나아감에 따라,　소비자 요청에 대한 빠르고 효율적인 처리는 높은 풀필먼트 쓰루풋(throughput)의 보장,　컴퓨팅 자원에 대한 최소한의 부담,　및 소비자 만족의 유지에 중요하다.　
소비자 반환, 교환 및 취소를 처리하기 위해 작업 흐름을 편집하기 위한 현재 시스템은 복잡하며 일반 최종 사용자가 파악하기에 지나치게 복잡하다. 종래 기술은 종종 개발자 팀과 전체 부서가 작업 흐름을 변경하는 것을 수반한다. 작업 흐름 시스템을 유지하기 위해 개발자에게 비용을 지불하거나 전체 지원 부서를 유지하는 것은 엄청난 비용이 들 수 있다. 또한 현재 시스템은 유연하지 않고 변경 사항을 구현하는데 시간이 소요된다. 가장 간단한 변경 작업도 구현에 몇 주가 소요된다.
풀필먼트 센터와 같이 빠른 속도로 진행되는 환경에서는 즉시 편집할 수 있는 능력이 중요하다. 컴퓨터 시스템을 사용하는 종래 작업 흐름 편집은 기술적이고 실용적인 관점에서 어렵다. 특히 비기술적 사용자는 반환 작업 흐름을 편집하는데 어려움이 있다.
그러므로, 개발자 및 다른 기술적 전문가의 개입이 없이 비기술적 사용자 및 사업부가 그들의 프로세스의 변경을 반영하기 위해 필요에 따라 작업 흐름을 변경할 수 있도록 작업 흐름을 편집하기 위한 개선된 방법 및 시스템이 요구된다.
본 개시의 일 형태는 작업 흐름 편집을 위한 시스템에 관한 것이다. 시스템은 인스트럭션들을 저장하는 메모리 및 상기 인스트럭션들을 실행하도록 설정된 적어도 하나의 프로세서를 포함할 수 있다. 상기 인스트럭션들은 프로세서로 하여금, 그래픽 사용자 인터페이스에 기존 작업 흐름을 표시하고, 상기 작업 흐름은 복수의 블록들을 포함하고, 사용자로부터 상기 복수의 블록들에 대한 편집을 수신하고, 편집은 적어도 개별 블록 또는 상기 복수의 블록들 간의 상호 연결에 대한 편집을 포함하도록 할 수 있다. 또한, 상기 인스트럭션들은 상기 수신된 편집에 기초하여 수정된 작업 흐름을 생성하고, 상기 시스템 내에서 상기 기존 작업 흐름을 대체하기 위해 상기 수정된 작업 흐름을 전파하고, 및 상기 수정된 작업 흐름을 상기 그래픽 사용자 인터페이스에 표시하는 것을 포함할 수 있다.
본 개시의 다른 형태는 작업 흐름 편집 방법에 관한 것이다. 방법은 그래픽 사용자 인터페이스에 기존 작업 흐름을 표시하고, 상기 작업 흐름은 복수의 블록들을 포함하고, 사용자로부터 상기 복수의 블록들에 대한 편집을 수신하고, 편집은 적어도 개별 블록 또는 상기 복수의 블록들 간의 상호 연결에 대한 편집을 포함하는 스텝들을 포함할 수 있다. 또한 상기 방법은 상기 수신된 편집에 기초하여 수정된 작업 흐름을 생성하고, 상기 시스템 내에서 상기 기존 작업 흐름을 대체하기 위해 상기 수정된 작업 흐름을 전파하고, 및 상기 수정된 작업 흐름을 상기 그래픽 사용자 인터페이스에 표시하는 추가적인 스텝들을 포함할 수 있다.
본 개시의 또 다른 형태는 작업 흐름 편집에 관한 것이고, 상기 작업 흐름은 복수의 블록들을 포함한다. 그리고 블록 자체는 다양한 인스트럭션들을 포함할 수 있다. 상기 인스트럭션들은: 결제 전에 주문이 취소되었는지 여부를 결정하고; 프로모션이 상기 주문에 적용되는지 여부를 결정하고; 상기 주문의 유형을 결정하고; 취소를 승인하거나 거절하고; 상기 취소 요청의 기록을 생성하는 것을 포함할 수 있다. 또한 상기 주문의 유형이 이벤트 티켓이면 상기 인스트럭션들은 상기 이벤트 티켓을 무효화하고; 이벤트 장소를 알리고; 상기 이벤트 티켓 취소를 등록하고; 상기 이벤트 취소에 대한 영수증을 생성하는 것을 포함할 수 있다. 또한 상기 주문의 유형이 제품이면 상기 인스트럭션들은 상기 제품 취소 정보를 등록하고; 상기 제품의 현재 풀필먼트 상태를 결정하고; 반환 작업 흐름을 시작하고; 상기 제품에 대한 환불을 처리하는 것을 포함할 수 있다. 상기 인스트럭션들은 반환을 승인하기 위한 데이터를 검색하고; 제3 자 반환인지 여부를 결정하고; 반환 요청을 등록하고; 소비자 유형을 결정하고; 무료 반환에 대한 적격성을 결정하고; 미반환 환불에 대한 적격성을 결정하는 것을 더 포함할 수 있다. 추가적으로, 상기 인스트럭션들은 반환 후 프로세스를 설정하고; 풀필먼트 상태를 결정하고; 회수를 요청하고; 상기 회수 상태를 확인하고; 반환을 승인하거나 거절하고; 주문 취소 작업 흐름을 시작하는 것을 포함할 수 있다. 게다가, 상기 인스트럭션들은 회수 트래킹 유형을 결정하고; 교환 회수가 가능한지 여부를 결정하고; 회수 정보 업데이트를 기록하고; 교환 배송 요청 여부를 결정하고; 회수를 위한 재시도 조건을 설정하고; 상기 재시도 조건을 업데이트하고; 자동 취소에 대한 적격성을 결정하고; 취소 작업 흐름을 시작하는 것을 포함할 수 있다. 마지막으로, 인스트럭션들은 또한 환불에 대한 적격성을 결정하고; 환불 알림을 발행하고; 철회 요청에 의해 영향을 받는 보류중인 작업 흐름을 결정하고; 상기 철회 요청에 기초하여 상기 보류중인 작업 흐름을 취소하는 것을 포함하는 것을 포함할 수 있다.
본 개시의 또 다른 형태는 흐름 편집을 위한 컴퓨터 구현 시스템에 관한 것이다. 상기 시스템은 인스트럭션들을 저장하는 메모리; 및 상기 인스트럭션들을 실행하도록 설정된 적어도 하나의 프로세서를 포함할 수 있다. 인스트럭션들은 그래픽 사용자 인터페이스에 반환 작업 흐름을 표시하는 것을 포함할 수 있고, 상기 작업 흐름은 복수의 연속적인 블록들을 포함하고, 상기 복수의 블록들은: 반환을 승인하기 위한 데이터를 검색하기 위한 인스트럭션들을 포함하는 제1 블록; 제3 자 반환인지 여부를 결정하기 위한 인스트럭션들을 포함하는 제2 블록; 반환 요청을 등록하기 위한 인스트럭션들을 포함하는 제3 블록; 소비자 유형을 결정하기 위한 인스트럭션들을 포함하는 제4 블록; 무료 반환에 대한 적격성을 결정하기 위한 인스트럭션들을 포함하는 제5 블록; 및 미반환 환불에 대한 적격성을 결정하기 위한 인스트럭션들을 포함하는 제6 블록을 포함한다. 인스트럭션들은 사용자로부터 상기 복수의 블록들에 대한 편집을 수신하고, 편집은 적어도 상기 복수의 블록들에서 블록들 중 하나의 제거를 포함하고, 상기 수신된 편집에 기초하여 수정된 작업 흐름을 생성하고, 상기 시스템 내에서 상기 기존 작업 흐름을 대체하기 위해 상기 수정된 작업 흐름을 전파하고, 및 상기 수정된 작업 흐름을 상기 그래픽 사용자 인터페이스에 표시하는 것을 더 포함할 수 있다.
또한 다른 시스템, 방법, 및 컴퓨터 판독 가능 매체가 여기서 논의된다.
도 1a는 개시된 실시예에 따른, 배송, 운송, 및 물류 운영을 가능하게 하는 통신을 위한 컴퓨터 시스템을 포함하는 네트워크의 예시적인 실시예를 나타낸 개략적인 블록도이다.
도 1b는 개시된 실시예에 따른, 상호 동작 사용자 인터페이스 요소에 따라 검색 요청을 만족시키는 하나 이상의 검색 결과를 포함하는 검색 결과 페이지(SRP; Search Result Page)의 샘플을 나타낸 도면이다.
도 1c는 개시된 실시예에 따른, 상호 동작 사용자 인터페이스 요소에 따라 제품 및 제품에 대한 정보를 포함하는 싱글 디스플레이 페이지(SDP; Single Display Page)의 샘플을 나타낸 도면이다.
도 1d는 개시된 실시예에 따른, 상호 동작 사용자 인터페이스 요소에 따라 가상의 쇼핑 장바구니에 아이템을 포함하는 장바구니 페이지의 샘플을 나타낸 도면이다.
도 1e는 개시된 실시예에 따른, 상호 동작 사용자 인터페이스 요소에 따라, 가상의 쇼핑 장바구니와 구매 및 배송에 관한 정보를 포함하는 주문 페이지의 샘플을 나타낸 도면이다.
도 2는 개시된 실시예에 따른, 개시된 컴퓨터 시스템을 활용하도록 구성된 예시적인 풀필먼트(fulfillment) 센터의 개략적인 도면이다.
도 3a는 인테이크(intake) 서브-시스템(300)의 예시적인 픽토그래픽(pictographic) 표시를 나타낸다.
도 3b는 출력 서브-시스템(325)의 예시적인 픽토그래픽 표시를 나타낸다.
도 3c는 개시된 실시예에 따른, 예시적인 제어 서브-시스템, 예시적인 반환 이벤트 스토어, 예시적인 규칙 엔진, 및 예시적인 외부 데이터 소스의 픽토그래픽 표시를 나타낸다.
도 3d는 개시된 실시예에 따른, 작업 흐름 서브-시스템의 예시적인 픽토그래픽 표시를 나타낸다.
도 4는 개시된 실시예에 따른, 작업 흐름 편집에 대한 예시적인 프로세스의 흐름도를 도시한다.
도 5는 개시된 실시예에 따른, 취소 작업 흐름을 포함하는 블록의 예시적인 배열을 나타낸다.
도 6은 개시된 실시예에 따른, 취소 후 작업 흐름을 포함하는 블록의 예시적인 배열을 나타낸다.
도 7은 개시된 실시예에 따른, 취소 승인 작업 흐름을 포함하는 블록의 예시적인 배열을 나타낸다.
도 8은 개시된 실시예에 따른, 취소 후 발송 중지 작업 흐름을 포함하는 블록의 예시적인 배열을 나타낸다.
도 9는 개시된 실시예에 따른, 반환 작업 흐름을 포함하는 블록의 예시적인 배열을 나타낸다.
도 10은 개시된 실시예에 따른, 반환 후 프로세스 작업 흐름을 포함하는 블록의 예시적인 배열을 나타낸다.
도 11은 개시된 실시예에 따른, 반환 승인 작업 흐름을 포함하는 블록의 예시적인 배열을 나타낸다.
도 12는 개시된 실시예에 따른, 교환 작업 흐름을 포함하는 블록의 예시적인 배열을 나타낸다.
도 13은 개시된 실시예에 따른, 교환 후 작업 흐름을 포함하는 블록의 예시적인 배열을 나타낸다.
도 14는 개시된 실시예에 따른, 미배송 교환 작업 흐름을 포함하는 블록의 예시적인 배열을 나타낸다.
도 15a 및 15b는 개시된 실시예에 따른, 트래킹 수집 작업 흐름을 포함하는 블록의 예시적인 배열을 나타낸다.
도 16은 개시된 실시예에 따른, 배달 트래킹 작업 흐름을 포함하는 블록의 예시적인 배열을 나타낸다.
도 17은 개시된 실시예에 따른, 수집 재시도 작업 흐름을 포함하는 블록의 예시적인 배열을 나타낸다.
도 18은 개시된 실시예에 따른, 수집 완료 작업 흐름을 포함하는 블록의 예시적인 배열을 나타낸다.
도 19는 개시된 실시예에 따른, 환불 요청 작업 흐름을 포함하는 블록의 예시적인 배열을 나타낸다.
도 20은 개시된 실시예에 따른, 환불 완료 작업 흐름을 포함하는 블록의 예시적인 배열을 나타낸다.
도 21은 개시된 실시예에 따른, 취소 철회 작업 흐름을 포함하는 블록의 예시적인 배열을 나타낸다.
도 22는 개시된 실시예에 따른, 반환 철회 작업 흐름을 포함하는 블록의 예시적인 배열을 나타낸다.
도 23은 개시된 실시예에 따른, 교환 철회 작업 흐름을 포함하는 블록의 예시적인 배열을 나타낸다.
이하의 상세한 설명은 첨부 도면을 참조한다. 가능하면, 동일한 참조 번호가 도면 및 이하의 설명에서 동일하거나 또는 유사한 부분을 참조하기 위해 사용된다. 몇몇 예시적인 실시예가 본 명세서에 설명되지만, 변형예, 적응예 및 다른 구현예가 가능하다. 예를 들면, 도면들에 도시된 구성 요소들 및 스텝들에 대한 대체예, 추가예 또는 변형예가 이루어질 수 있으며, 본 명세서에서 설명된 예시적 방법들은 개시된 방법들에 대해 스텝들을 대체, 재정렬, 제거 또는 추가함으로써 변형될 수 있다. 따라서 이하의 상세한 설명은 개시된 실시예들 및 예시들로 제한되지 않는다. 대신에, 본 발명의 적합한 범위는 첨부된 청구 범위에 의해 규정된다.
본 개시의 실시예는 작업 흐름 편집을 위해 구성된 시스템 및 방법에 관한 것이다. 특히, 일부 실시예는 아이템 반환 프로세스에 대한 작업 흐름 편집에 관한 것이다.
도 1a를 참조하면, 배송, 운송 및 물류 운영을 가능하게 하는 통신을 위한 컴퓨터 시스템을 포함하는 시스템의 실시예를 나타낸 개략적인 블록도(100)가 도시되어 있다. 도 1a에 도시된 바와 같이, 시스템(100)은 다양한 시스템을 포함할 수 있으며, 이들 각각은 하나 이상의 네트워크를 통해 서로 연결될 수 있다. 또한 시스템은 집적 연결을 통해, 예를 들어, 케이블을 이용하여, 서로 연결될 수 있다. 도시된 시스템은 배송 기관 기술(shipment authority technology, SAT) 시스템(101), 외부 프론트 엔드 시스템(external front end system, 103), 내부 프론트 엔드 시스템(105), 운송 시스템(107), 모바일 디바이스(107A, 107B, 107C), 판매자 포털(109), 배송 및 주문 트래킹(shipment and order tracking, SOT) 시스템(111), 풀필먼트 최적화(fulfillment optimization, FO) 시스템(113), 풀필먼트 메시징 게이트웨이(fulfillment messaging gateway, FMG)(115), 공급 체인 관리(supply chain management, SCM) 시스템(117), 창고 관리 시스템(warehouse management system, WMS)(119), 모바일 디바이스(119A, 119B, 119C)(풀필먼트 센터(fulfillment center, FC)(200) 내부에 있는 것으로 도시됨), 제3자 풀필먼트 시스템(121A, 121B, 121C), 풀필먼트 센터 인증 시스템(fulfillment center authorization system, FC Auth)(123), 및 노동 관리 시스템(labor management system, LMS)(125)을 포함한다.
일부 실시예에서, SAT 시스템(101)은 주문 상태와 배달 상태를 모니터링하는 컴퓨터 시스템으로서 구현될 수 있다. 예를 들면, SAT 시스템(101)은 주문이 약속된 배달 날짜(Promised Delivery Date, PDD)를 지났는지를 결정할 수 있고, 새로운 주문을 개시시키고, 배달되지 않은 주문의 아이템을 다시 배송하며, 배달되지 않은 주문을 취소하고, 주문 소비자와 연락을 시작하는 것 등을 포함하는 적합한 조치를 취할 수 있다. SAT 시스템(101)은 또한, (특정 기간 동안 배송된 패키지의 개수와 같은) 출력, 및 (배송시 사용하기 위해 수신된 빈 카드보드 박스의 개수와 같은) 입력을 포함하는 다른 데이터를 감시할 수 있다. 또한 SAT 시스템(101)은 외부 프론트 엔드 시스템(103) 및 FO 시스템(113)과 같은 디바이스들 간의 (예를 들면, 저장 전달(store-and-forward) 또는 다른 기술을 사용하는) 통신을 가능하게 하는 시스템(100) 내의 상이한 디바이스들 사이의 게이트웨이로서 동작할 수 있다.
일부 실시예에서, 외부 프론트 엔드 시스템(103)은 외부 사용자가 시스템(100) 내의 하나 이상의 시스템과 상호 동작할 수 있게 하는 컴퓨터 시스템으로서 구현될 수 있다. 예를 들면, 시스템(100)이 사용자가 아이템에 대한 주문을 할 수 있게 하는 시스템의 프레젠테이션을 가능하게 하는 실시예에서, 외부 프론트 엔드 시스템(103)은 검색 요청을 수신하고, 아이템 페이지를 제시하며, 결제 정보를 요청하는 웹 서버로서 구현될 수 있다. 예를 들면, 외부 프론트 엔드 시스템(103)은 Apache HTTP 서버, Microsoft Internet Information Services(IIS), NGINX 등과 같은 소프트웨어를 실행하는 컴퓨터 또는 컴퓨터들로서 구현될 수 있다. 다른 실시예에서, 외부 프론트 엔드 시스템(103)은 외부 디바이스(예를 들면, 모바일 디바이스(102A) 또는 컴퓨터(102B))로부터 요청을 수신 및 처리하고, 이들 요청에 기초하여 데이터베이스 및 다른 데이터 저장 장치로부터 정보를 획득하며, 획득한 정보에 기초하여 수신된 요청에 대한 응답을 제공하도록 설계된 커스텀 웹 서버 소프트웨어를 실행할 수 있다.
일부 실시예에서, 외부 프론트 엔드 시스템(103)은 웹 캐싱 시스템, 데이터베이스, 검색 시스템, 또는 결제 시스템 중 하나 이상을 포함할 수 있다. 일 양상에서, 외부 프론트 엔드 시스템(103)은 이들 시스템 중 하나 이상을 포함할 수 있는 반면, 다른 양상에서, 외부 프론트 엔드 시스템(103)은 이들 시스템 중 하나 이상에 연결된 인터페이스(예를 들면, 서버 대 서버, 데이터베이스 대 데이터베이스, 또는 다른 네트워크 연결)를 포함할 수 있다.
도 1b, 1c, 1d 및 1e에 의해 나타낸 스텝들의 예시적인 세트는 외부 프론트 엔드 시스템(103)의 일부 동작을 설명하는 것에 도움이 될 것이다. 외부 프론트 엔드 시스템(103)은 프레젠테이션 및/또는 디스플레이를 위해 시스템(100) 내의 시스템 또는 디바이스로부터 정보를 수신할 수 있다. 예를 들면, 외부 프론트 엔드 시스템(103)은 검색 결과 페이지(Search Result Page, SRP)(예를 들면, 도 1b), 싱글 디테일 페이지(Single Detail Page, SDP)(예를 들면, 도 1c), 장바구니 페이지(Cart page)(예를 들면, 도 1d), 또는 주문 페이지(예를 들면, 도 1e)를 포함하는 하나 이상의 웹페이지를 호스팅하거나 제공할 수 있다. (예를 들면, 모바일 디바이스(102A) 또는 컴퓨터(102B)를 사용하는) 사용자 디바이스는 외부 프론트 엔드 시스템(103)으로 이동하고 검색 박스에 정보를 입력함으로써 검색을 요청할 수 있다. 외부 프론트 엔드 시스템(103)은 시스템(100) 내의 하나 이상의 시스템으로부터 정보를 요청할 수 있다. 예를 들면, 외부 프론트 엔드 시스템(103)은 FO 시스템(113)으로부터 검색 요청을 만족하는 정보를 요청할 수 있다. 또한 외부 프론트 엔드 시스템(103)은 (FO 시스템(113)으로부터) 검색 결과에 포함된 각 제품에 대한 약속된 배달 날짜(Promised Delivery Date) 또는 "PDD"를 요청하고 수신할 수 있다. 일부 실시예에서, PDD는 특정 기간 이내, 예를 들면, 하루의 끝(PM 11:59)까지 주문되면, 사용자가 원하는 장소에 제품을 포함하는 패키지가 도착할 시점의 추정 또는 사용자가 원하는 장소에 제품이 배달될 것으로 약속된 날짜를 나타낼 수 있다. (PDD는 FO 시스템(113)과 관련하여 이하에서 더 논의된다.)
외부 프론트 엔드 시스템(103)은 정보에 기초하여 SRP(예를 들면, 도 1b)를 준비할 수 있다. SRP는 검색 요청을 만족하는 정보를 포함할 수 있다. 예를 들면, 이는 검색 요청을 만족하는 제품의 사진을 포함할 수 있다. 또한 SRP는 각 제품에 대한 각각의 가격, 또는 각 제품에 대한 개선된 배달 옵션, PDD, 무게, 크기, 오퍼(offer), 할인 등에 관한 정보를 포함할 수 있다. 외부 프론트 엔드 시스템(103)은 (예를 들면, 네트워크를 통해) SRP를 요청 사용자 디바이스로 보낼 수 있다.
이후 사용자 디바이스는 예를 들면, SRP에 나타난 제품을 선택하기 위하여 사용자 인터페이스를 클릭 또는 탭하거나, 또는 다른 입력 디바이스를 사용함으로써, SRP로부터 제품을 선택할 수 있다. 사용자 디바이스는 선택된 제품에 관한 정보에 대한 요청을 만들고 이를 외부 프론트 엔드 시스템(103)으로 전송할 수 있다. 이에 응답하여, 외부 프론트 엔드 시스템(103)은 선택된 제품에 관한 정보를 요청할 수 있다. 예를 들면, 정보는 각각의 SRP 상에 제품에 대해 제시된 것 이상의 추가 정보를 포함할 수 있다. 이는, 예를 들면, 유통 기한, 원산지, 무게, 크기, 패키지 내의 아이템 개수, 취급 지침, 또는 제품에 대한 다른 정보를 포함할 수 있다. 또한 정보는 (예를 들면, 이 제품 및 적어도 하나의 다른 제품을 구입한 소비자들의 빅 데이터 및/또는 기계 학습 분석에 기초한) 유사한 제품에 대한 추천, 자주 묻는 질문에 대한 답변, 소비자의 후기, 제조 업체 정보, 사진 등을 포함할 수 있다.
외부 프론트 엔드 시스템(103)은 수신된 제품 정보에 기초하여 SDP(Single Detail Page)(예를 들면, 도 1c)를 준비할 수 있다. SDP는 또한, "지금 구매(Buy Now)" 버튼, "장바구니에 추가(Add to Cart)" 버튼, 수량 필드, 아이템 사진 등과 같은 다른 상호 동작 요소를 포함할 수 있다. SDP는 제품을 제시하는 판매자의 목록을 더 포함할 수 있다. 목록은 제품을 가장 낮은 가격에 판매할 것을 제시하는 판매자가 맨 위에 나열될 수 있도록 각 판매자가 제시하는 가격에 기초하여 정렬될 수 있다. 또한 목록은 가장 높게 랭크된 판매자가 맨 위에 나열될 수 있도록 판매자 랭킹에 기초하여 정렬될 수 있다. 판매자 랭킹은, 예를 들면, 제안된 PDD를 만족하는 판매자 과거 추적 이력을 포함하는 다중 인자들에 기초하여 만들어질 수 있다. 외부 프론트 엔드 시스템(103)은 (예를 들면, 네트워크를 통해) SDP를 요청 사용자 디바이스로 전달할 수 있다.
요청 사용자 디바이스는 제품 정보를 나열하는 SDP를 수신할 수 있다. SDP를 수신하면, 사용자 디바이스는 SDP와 상호 동작할 수 있다. 예를 들면, 요청 사용자 디바이스의 사용자는 SDP의 "장바구니에 담기(Place in Cart)" 버튼을 클릭하거나, 이와 상호 동작할 수 있다. 이렇게 하면 사용자와 연계된 쇼핑 장바구니에 제품이 추가된다. 사용자 디바이스는 제품을 쇼핑 장바구니에 추가하기 위해 외부 프론트 엔드 시스템(103)으로 이러한 요청을 전송할 수 있다.
외부 프론트 엔드 시스템(103)은 장바구니 페이지(예를 들면, 도 1d)를 생성할 수 있다. 일부 실시예에서, 장바구니 페이지는 사용자가 가상의 "쇼핑 장바구니(shopping cart)"에 추가한 제품을 나열한다. 사용자 디바이스는 SRP, SDP, 또는 다른 페이지의 아이콘을 클릭하거나, 상호 동작함으로써 장바구니 페이지를 요청할 수 있다. 일부 실시예에서, 장바구니 페이지는 사용자가 장바구니에 추가한 모든 제품 뿐 아니라 각 제품의 수량, 각 제품의 품목당 가격, 관련 수량에 기초한 각 제품의 가격, PDD에 관한 정보, 배달 방법, 배송 비용, 쇼핑 장바구니의 제품을 수정(예를 들면, 수량의 삭제 또는 수정)하기 위한 사용자 인터페이스 요소, 다른 제품의 주문 또는 제품의 정기적인 배달 설정에 대한 옵션, 할부(interest payment) 설정에 대한 옵션, 구매를 진행하기 위한 사용자 인터페이스 요소 등과 같은 장바구니의 제품에 관한 정보를 나열할 수 있다. 사용자 디바이스의 사용자는 쇼핑 장바구니에 있는 제품의 구매를 시작하기 위해 사용자 인터페이스 요소(예를 들면, "지금 구매(Buy Now)"라고 적혀있는 버튼)를 클릭하거나, 이와 상호 동작할 수 있다. 그렇게 하면, 사용자 디바이스는 구매를 시작하기 위해 이러한 요청을 외부 프론트 엔드 시스템(103)으로 전송할 수 있다.
외부 프론트 엔드 시스템(103)은 구매를 시작하는 요청을 수신하는 것에 응답하여 주문 페이지(예를 들면, 도 1e)를 생성할 수 있다. 일부 실시예에서, 주문 페이지는 쇼핑 장바구니로부터의 아이템을 재나열하고, 결제 및 배송 정보의 입력을 요청한다. 예를 들면, 주문 페이지는 쇼핑 장바구니의 아이템 구매자에 관한 정보(예를 들면, 이름, 주소, 이메일 주소, 전화번호), 수령인에 관한 정보(예를 들면, 이름, 주소, 전화번호, 배달 정보), 배송 정보(예를 들면, 배달 및/또는 픽업 속도/방법), 결제 정보(예를 들면, 신용 카드, 은행 송금, 수표, 저장된 크레딧), 현금 영수증을 요청하는 사용자 인터페이스 요소(예를 들면, 세금 목적) 등을 요청하는 섹션을 포함할 수 있다. 외부 프론트 엔드 시스템(103)은 사용자 디바이스에 주문 페이지를 전송할 수 있다.
사용자 디바이스는 주문 페이지에 정보를 입력하고 외부 프론트 엔드 시스템(103)으로 정보를 전송하는 사용자 인터페이스 요소를 클릭하거나, 상호 동작할 수 있다. 그로부터, 외부 프론트 엔드 시스템(103)은 정보를 시스템(100) 내의 다른 시스템으로 전송하여 쇼핑 장바구니의 제품으로 새로운 주문을 생성하고 처리할 수 있도록 한다.
일부 실시예에서, 외부 프론트 엔드 시스템(103)은 판매자가 주문과 관련된 정보를 전송 및 수신할 수 있도록 추가로 구성될 수 있다.
일부 실시예에서, 내부 프론트 엔드 시스템(105)은 내부 사용자(예를 들면, 시스템(100)을 소유, 운영 또는 임대하는 조직의 직원)가 시스템(100) 내의 하나 이상의 시스템과 상호작용할 수 있게 하는 컴퓨터 시스템으로서 구현될 수 있다. 예를 들면, 시스템(100)이 사용자가 아이템에 대한 주문을 할 수 있게 하는 시스템의 프레젠테이션을 가능하게 하는 실시예에서, 내부 프론트 엔드 시스템(105)은 내부 사용자가 주문에 대한 진단 및 통계 정보를 볼 수 있게 하고, 아이템 정보를 수정하며, 또는 주문에 대한 통계를 검토할 수 있게 하는 웹 서버로서 구현될 수 있다. 예를 들면, 내부 프론트 엔드 시스템(105)은 Apache HTTP 서버, Microsoft Internet Information Services(IIS), NGINX 등과 같은 소프트웨어를 실행하는 컴퓨터 또는 컴퓨터들로서 구현될 수 있다. 다른 실시예에서, 내부 프론트 엔드 시스템(105)은 (도시되지 않은 다른 디바이스뿐 아니라) 시스템(100) 내에 나타낸 시스템 또는 디바이스로부터 요청을 수신 및 처리하고, 그러한 요청에 기초하여 데이터베이스 및 다른 데이터 저장 장치로부터 정보를 획득하며, 획득한 정보에 기초하여 수신된 요청에 대한 응답을 제공하도록 설계된 커스텀 웹 서버 소프트웨어를 실행할 수 있다.
일부 실시예에서, 내부 프론트 엔드 시스템(105)은 웹 캐싱 시스템, 데이터베이스, 검색 시스템, 결제 시스템, 분석 시스템, 주문 모니터링 시스템 등 중 하나 이상을 포함할 수 있다. 일 양상에서, 내부 프론트 엔드 시스템(105)은 이들 시스템 중 하나 이상을 포함할 수 있는 반면, 다른 양상에서는 내부 프론트 엔드 시스템(105)은 이들 시스템 중 하나 이상에 연결된 인터페이스(예를 들면, 서버 대 서버, 데이터베이스 대 데이터베이스, 또는 다른 네트워크 연결)를 포함할 수 있다.
일부 실시예에서, 운송 시스템(107)은 시스템(100) 내의 시스템 또는 디바이스와 모바일 디바이스(107A-107C) 간의 통신을 가능하게 하는 컴퓨터 시스템으로서 구현될 수 있다. 일부 실시예에서, 운송 시스템(107)은 하나 이상의 모바일 디바이스(107A-107C)(예를 들면, 휴대 전화, 스마트폰, PDA 등)로부터 정보를 수신할 수 있다. 예를 들면, 일부 실시예에서, 모바일 디바이스(107A-107C)는 배달원에 의해 동작되는 디바이스를 포함할 수 있다. 정규직, 임시직 또는 교대 근무자일 수 있는 배달원은 사용자에 의해 주문된 제품을 포함하는 패키지의 배달을 위해 모바일 디바이스(107A-107C)를 이용할 수 있다. 예를 들면, 패키지를 배달하기 위해, 배달원은 배달할 패키지와 배달할 위치를 나타내는 모바일 디바이스 상의 알림을 수신할 수 있다. 배달 장소에 도착하면, 배달원은 (예를 들면, 트럭의 뒤나 패키지들의 크레이트(crate) 내의) 패키지를 찾을 수 있고, 모바일 디바이스를 사용하여 패키지 상의 식별자와 관련된 데이터(예를 들면, 바코드, 이미지, 문자열, RFID 태그 등)를 스캔하거나 캡처하며, (예를 들면, 현관문에 놓거나, 경비원에게 맡기거나, 수령인에게 전달하는 것 등에 의해) 패키지를 배달할 수 있다. 일부 실시예에서, 배달원은 모바일 디바이스를 이용하여 패키지의 사진(들)을 찍거나 및/또는 서명을 받을 수 있다. 모바일 디바이스는, 예를 들면, 시간, 날짜, GPS 위치, 사진(들), 배달원에 관련된 식별자, 모바일 디바이스에 관련된 식별자 등을 포함하는 배달에 관한 정보를 포함하는 정보를 운송 시스템(107)에 보낼 수 있다. 운송 시스템(107)은 시스템(100) 내의 다른 시스템에 의한 액세스를 위해 데이터베이스(미도시)에 이러한 정보를 저장할 수 있다. 일부 실시예에서, 운송 시스템(107)은 다른 시스템에 특정 패키지의 위치를 나타내는 트래킹 데이터를 준비 및 전송하기 위해 이러한 정보를 사용할 수 있다.
일부 실시예에서, 특정 사용자는, 한 종류의 모바일 디바이스를 사용할 수 있는 반면(예를 들면, 정규 직원은 바코드 스캐너, 스타일러스 및 다른 디바이스와 같은 커스텀 하드웨어를 갖는 전문 PDA를 사용할 수 있음), 다른 사용자는 다른 종류의 모바일 디바이스를 사용할 수 있다(예를 들면, 임시 또는 교대 근무 직원이 기성 휴대 전화 및/또는 스마트폰을 사용할 수 있음).
일부 실시예에서, 운송 시스템(107)은 사용자를 각각의 디바이스와 연관시킬 수 있다. 예를 들면, 운송 시스템(107)은 사용자(예를 들면, 사용자 식별자, 직원 식별자, 또는 전화번호에 의해 표현됨)와 모바일 디바이스(예를 들면, International Mobile Equipment Identity(IMEI), International Mobile Subscription Identifier(IMSI), 전화번호, Universal Unique Identifier(UUID), 또는 Globally Unique Identifier(GUID)에 의해 표현됨) 간의 연관성을 저장할 수 있다. 운송 시스템(107)은, 다른 것들 중에 작업자의 위치, 작업자의 효율성, 또는 작업자의 속도를 결정하기 위해 데이터베이스에 저장된 데이터를 분석하기 위해 배달시 수신되는 데이터와 함께 이러한 연관성을 사용할 수 있다.
일부 실시예에서, 판매자 포털(109)은 판매자 또는 다른 외부 엔터티(entity)가 시스템(100) 내의 하나 이상의 시스템과 전기적으로 통신할 수 있게 하는 컴퓨터 시스템으로서 구현될 수 있다. 예를 들면, 판매자는 판매자 포털(109)을 이용하여 판매자가 시스템(100)을 통해 판매하고자 하는 제품에 대한 제품 정보, 주문 정보, 연락처 정보 등을 업로드하거나 제공하기 위하여 컴퓨터 시스템(미도시)을 이용할 수 있다.
일부 실시예에서, 배송 및 주문 트래킹 시스템(111)은 소비자(예를 들면, 디바이스(102A-102B)를 사용하는 사용자)에 의해 주문된 제품을 포함하는 패키지의 위치에 관한 정보를 수신, 저장 및 포워딩하는 컴퓨터 시스템으로서 구현될 수 있다. 일부 실시예에서, 배송 및 주문 트래킹 시스템(111)은 소비자에 의해 주문된 제품을 포함하는 패키지를 배달하는 배송 회사에 의해 운영되는 웹 서버(미도시)로부터 정보를 요청하거나 저장할 수 있다.
일부 실시예에서, 배송 및 주문 트래킹 시스템(111)은 시스템(100)에 나타낸 시스템들로부터 정보를 요청하고 저장할 수 있다. 예를 들면, 배송 및 주문 트래킹 시스템(111)은 운송 시스템(107)으로부터 정보를 요청할 수 있다. 전술한 바와 같이, 운송 시스템(107)은 사용자(예를 들면, 배달원) 또는 차량(예를 들면, 배달 트럭) 중 하나 이상과 연관된 하나 이상의 모바일 디바이스(107A-107C)(예를 들면, 휴대 전화, 스마트폰, PDA 등)로부터 정보를 수신할 수 있다. 일부 실시예에서, 배송 및 주문 트래킹 시스템(111)은 또한, 풀필먼트 센터(예를 들면, 풀필먼트 센터(200)) 내부의 개별 제품의 위치를 결정하기 위해 창고 관리 시스템(WMS)(119)으로부터 정보를 요청할 수 있다. 배송 및 주문 트래킹 시스템(111)은 운송 시스템(107) 또는 WMS(119) 중 하나 이상으로부터 데이터를 요청하고, 이를 처리하며, 요청시 디바이스(예를 들면, 사용자 디바이스(102A, 102B))로 이를 제공할 수 있다.
일부 실시예에서, 풀필먼트 최적화(FO) 시스템(113)은 다른 시스템(예를 들면, 외부 프론트 엔드 시스템(103) 및/또는 배송 및 주문 트래킹 시스템(111))으로부터의 소비자 주문에 대한 정보를 저장하는 컴퓨터 시스템으로서 구현될 수 있다. 또한 FO 시스템(113)은 특정 아이템이 유지 또는 저장되는 곳을 나타내는 정보를 저장할 수 있다. 예를 들면, 특정 아이템은 하나의 풀필먼트 센터에만 저장될 수 있는 반면, 다른 특정 아이템은 다수의 풀필먼트 센터에 저장될 수 있다. 또 다른 실시예에서, 특정 풀필먼트 센터는 아이템의 특정 세트(예를 들면, 신선한 농산물 또는 냉동 제품)만을 저장하도록 구성될 수 있다. FO 시스템(113)은 이러한 정보뿐 아니라 관련 정보(예를 들면, 수량, 크기, 수령 날짜, 유통 기한 등)를 저장한다.
또한 FO 시스템(113)은 각 제품에 대해 대응하는 PDD(약속된 배달 날짜)를 계산할 수 있다. 일부 실시예에서, PDD는 하나 이상의 요소에 기초할 수 있다. 예를 들면, FO 시스템(113)은 제품에 대한 과거 수요(예를 들면, 그 제품이 일정 기간 동안 얼마나 주문되었는지), 제품에 대한 예측된 수요(예를 들면, 얼마나 많은 소비자가 다가오는 기간 동안 제품을 주문할 것으로 예상되는지), 일정 기간 동안 얼마나 많은 제품이 주문되었는지를 나타내는 네트워크 전반의 과거 수요, 다가오는 기간 동안 얼마나 많은 제품이 주문될 것으로 예상되는지를 나타내는 네트워크 전반의 예측된 수요, 각각의 제품을 저장하는 각 풀필먼트 센터(200)에 저장된 제품의 하나 이상의 개수, 그 제품에 대한 예상 또는 현재 주문 등에 기초하여 제품에 대한 PDD를 계산할 수 있다.
일부 실시예에서, FO 시스템(113)은 주기적으로(예를 들면, 시간별로) 각 제품에 대한 PDD를 결정하고, 검색 또는 다른 시스템(예를 들면, 외부 프론트 엔드 시스템(103), SAT 시스템(101), 배송 및 주문 트래킹 시스템(111))으로의 전송을 위해 이를 데이터베이스에 저장할 수 있다. 다른 실시예에서, FO 시스템(113)은 하나 이상의 시스템(예를 들면, 외부 프론트 엔드 시스템(103), SAT 시스템(101), 배송 및 주문 트래킹 시스템(111))으로부터 전자 요청을 수신하고 요구에 따라 PDD를 계산할 수 있다.
일부 실시예에서, 풀필먼트 메시징 게이트웨이(FMG)(115)는 FO 시스템(113)과 같은 시스템(100) 내의 하나 이상의 시스템으로부터 어느 한 포맷 또는 프로토콜로 요청 또는 응답을 수신하고, 이를 다른 포맷 또는 프로토콜로 변환하고, 이를 변환된 포맷 또는 프로토콜로 WMS(119) 또는 제3자 풀필먼트 시스템(121A, 121B, 또는 121C)과 같은 다른 시스템에 포워딩하며, 반대의 경우도 가능한 컴퓨터 시스템으로서 구현될 수 있다.
일부 실시예에서, 공급 체인 관리(SCM) 시스템(117)은 예측 기능을 수행하는 컴퓨터 시스템으로서 구현될 수 있다. 예를 들면, SCM 시스템(117)은, 예를 들어 제품에 대한 과거 수요, 제품에 대한 예측된 수요, 네트워크 전반의 과거 수요, 네트워크 전반의 예측된 수요, 각각의 풀필먼트 센터(200)에 저장된 제품 개수, 각 제품에 대한 예상 또는 현재 주문 등에 기초하여, 특정 제품에 대한 수요의 수준을 예측할 수 있다. 이러한 예측된 수준과 모든 풀필먼트 센터의 각 제품의 수량에 응답하여, SCM 시스템(117)은 특정 제품에 대한 예측 수요를 만족시키기 위하여, 하나 이상의 구매 주문을 생성하고 충분한 양을 비축할 수 있다.
일부 실시예에서, 창고 관리 시스템(WMS)(119)은 작업 흐름을 모니터링하는 컴퓨터 시스템으로서 구현될 수 있다. 예를 들면, WMS(119)는 개개의 디바이스(예를 들면, 디바이스(107A-107C 또는 119A-119C))로부터 개별 이벤트를 나타내는 이벤트 데이터를 수신할 수 있다. 예를 들면, WMS(119)는 패키지를 스캔하기 위해 이들 디바이스 중 하나를 사용한 것을 나타내는 이벤트 데이터를 수신할 수 있다. 풀필먼트 센터(200) 및 도 2에 관하여 이하에서 논의되는 바와 같이, 풀필먼트 프로세스 동안, 패키지 식별자(예를 들면, 바코드 또는 RFID 태그 데이터)는 특정 단계에서 기계(예를 들면, 자동 또는 핸드헬드 바코드 스캐너, RFID 판독기, 고속 카메라, 태블릿(119A), 모바일 디바이스/PDA(119B), 컴퓨터(119C)와 같은 디바이스 등)에 의해 스캔되거나 판독될 수 있다. WMS(119)는 패키지 식별자, 시간, 날짜, 위치, 사용자 식별자, 또는 다른 정보와 함께 대응하는 데이터베이스(미도시)에 패키지 식별자의 스캔 또는 판독을 나타내는 각 이벤트를 저장할 수 있고, 이러한 정보를 다른 시스템(예를 들면, 배송 및 주문 트래킹 시스템(111))에 제공할 수 있다.
일부 실시예에서, WMS(119)는 하나 이상의 디바이스(예를 들면, 디바이스(107A-107C 또는 119A-119C))와 시스템(100)에 연관된 하나 이상의 사용자를 연관시키는 정보를 저장할 수 있다. 예를 들면, 몇몇 상황에서, (파트 타임 또는 풀 타임 직원과 같은) 사용자는 모바일 디바이스(예를 들면, 모바일 디바이스는 스마트폰임)를 소유한다는 점에서, 모바일 디바이스와 연관될 수 있다. 다른 상황에서, 사용자는 임시로 모바일 디바이스를 보관한다는 점에서(예를 들면, 하루의 시작에서부터 모바일 디바이스를 대여받은 사용자가, 하루 동안 그것을 사용하고, 하루가 끝날 때 그것을 반납할 것임), 모바일 디바이스와 연관될 수 있다.
일부 실시예에서, WMS(119)는 시스템(100)과 연관된 각각의 사용자에 대한 작업 로그를 유지할 수 있다. 예를 들면, WMS(119)는 임의의 할당된 프로세스(예를 들면, 트럭에서 내리기, 픽업 구역에서 아이템을 픽업하기, 리빈 월(rebin wall) 작업, 아이템 패킹하기), 사용자 식별자, 위치(예를 들면, 풀필먼트 센터(200)의 플로어(floor) 또는 구역), 직원에 의해 시스템을 통해 이동된 유닛의 수(예를 들면, 픽업된 아이템의 수, 패킹된 아이템의 수), 디바이스(예를 들면, 디바이스(119A-119C))와 관련된 식별자 등을 포함하는 각 직원과 관련된 정보를 저장할 수 있다. 일부 실시예에서, WMS(119)는 디바이스(119A-119C)에서 동작되는 계시(timekeeping) 시스템과 같은 계시 시스템으로부터 체크-인 및 체크-아웃 정보를 수신할 수 있다.
일부 실시예에서, 제3자 풀필먼트 (3PL) 시스템(121A-121C)은 물류 및 제품의 제3자 제공자와 관련된 컴퓨터 시스템을 나타낸다. 예를 들면, (도 2와 관련하여 이하에서 후술하는 바와 같이) 일부 제품이 풀필먼트 센터(200)에 저장되는 반면, 다른 제품은 오프 사이트(off-site)에 저장될 수 있거나, 수요에 따라 생산될 수 있거나, 달리 풀필먼트 센터(200)에 저장될 수 없을 수 있다. 3PL 시스템(121A-121C)은 FO 시스템(113)으로부터 (예를 들면, FMG(115)를 통해) 주문을 수신하도록 구성될 수 있으며, 소비자에게 직접 제품 및/또는 서비스(예를 들면, 배달 또는 설치)를 제공할 수 있다. 일부 실시예에서, 하나 이상의 3PL 시스템(121A-112C)은 시스템(100)의 일부일 수 있는 반면, 다른 실시예에서, 하나 이상의 3PL 시스템(121A-112C)은 시스템(100)의 외부에 존재할 수 있다(예를 들면, 제3자 제공자에 의해 소유되거나 운영됨).
일부 실시예에서, 풀필먼트 센터 인증 시스템(FC Auth)(123)은 다양한 기능을 갖는 컴퓨터 시스템으로서 구현될 수 있다. 예를 들면, 일부 실시예에서, FC Auth(123)는 시스템(100) 내의 하나 이상의 다른 시스템에 대한 단일-사인 온(single-sign on, SSO) 서비스로서 작동할 수 있다. 예를 들면, FC Auth(123)는 내부 프론트 엔드 시스템(105)을 통해 사용자가 로그인할 수 있도록 하고, 사용자가 배송 및 주문 트래킹 시스템(111)에서 리소스에 액세스하기 위해 유사한 권한을 갖고 있다고 결정하며, 두 번째 로그인 프로세스 요구 없이 사용자가 그러한 권한에 액세스할 수 있게 할 수 있다. 다른 실시예에서, FC Auth(123)는 사용자(예를 들면, 직원)가 자신을 특정 작업과 연관시킬 수 있게 할 수 있다. 예를 들면, 일부 직원은 (디바이스(119A-119C)와 같은) 전자 디바이스를 갖지 않을 수 있으며, 대신 하루 동안 풀필먼트 센터(200) 내에서 작업들 사이 및 구역들 사이에서 이동할 수 있다. FC Auth(123)는 이러한 직원들이 상이한 시간 대에 수행 중인 작업과 속해 있는 구역을 표시할 수 있도록 구성될 수 있다.
일부 실시예에서, 노동 관리 시스템(LMS)(125)은 직원(풀-타임 및 파트-타임 직원을 포함함)에 대한 출근 및 초과 근무 정보를 저장하는 컴퓨터 시스템으로서 구현될 수 있다. 예를 들면, LMS(125)는 FC Auth(123), WMS(119), 디바이스(119A-119C), 운송 시스템(107), 및/또는 디바이스(107A-107C)로부터 정보를 수신할 수 있다.
도 1a에 나타낸 특정 구성은 단지 예시일 뿐이다. 예를 들면, 도 1a는 FO 시스템(113)에 연결된 FC Auth 시스템(123)을 나타낸 반면, 모든 실시예가 이러한 특정 구성을 필요로 하는 것은 아니다. 실제로, 일부 실시예에서, 시스템(100) 내의 시스템은 인터넷, 인트라넷, WAN(Wide-Area Network), MAN(Metropolitan-Area Network), IEEE 802.11a/b/g/n 표준을 따르는 무선 네트워크, 임대 회선 등을 포함하는 하나 이상의 공공 또는 사설 네트워크를 통해 연결될 수 있다. 일부 실시예에서, 시스템(100) 내의 하나 이상의 시스템은 데이터 센터, 서버 팜(farm) 등에서 구현되는 하나 이상의 가상 서버로서 구현될 수 있다.
도 2는 풀필먼트 센터(200)를 나타낸다. 풀필먼트 센터(200)는 주문시 소비자에게 배송하기 위한 아이템을 저장하는 물리적 장소의 예시이다. 풀필먼트 센터(FC)(200)는 다수의 구역으로 분할될 수 있으며, 각각이 도 2에 도시된다. 일부 실시예에서, 이러한 "구역(zones)"은 아이템을 수령하고, 아이템을 저장하고, 아이템을 검색하고, 아이템을 배송하는 과정의 상이한 스텝 사이의 가상 구분으로 생각될 수 있다. 따라서, "구역"이 도 2에 나타나 있으나, 일부 실시예에서, 구역의 다른 구분도 가능하고, 도 2의 구역은 생략, 복제, 또는 수정될 수 있다.
인바운드 구역(203)은 도 1a의 시스템(100)을 사용하여 제품을 판매하고자 하는 판매자로부터 아이템이 수신되는 FC(200)의 영역을 나타낸다. 예를 들면, 판매자는 트럭(201)을 사용하여 아이템(202A, 202B)을 배달할 수 있다. 아이템(202A)은 자신의 배송 팔레트(pallet)를 점유하기에 충분히 큰 단일 아이템을 나타낼 수 있는 반면, 아이템(202B)은 공간을 절약하기 위해 동일한 팔레트 상에 함께 적층되는 아이템의 세트를 나타낼 수 있다.
작업자는 인바운드 구역(203)의 아이템을 수령하고, 선택적으로 컴퓨터 시스템(미도시)을 사용하여 아이템이 손상되었는지 및 정확한지를 체크할 수 있다. 예를 들면, 작업자는 아이템(202A, 202B)의 수량을 아이템의 주문 수량과 비교하기 위해 컴퓨터 시스템을 사용할 수 있다. 수량이 일치하지 않는다면, 해당 작업자는 아이템(202A, 202B) 중 하나 이상을 거부할 수 있다. 수량이 일치한다면, 작업자는 그 아이템들을 (예를 들면, 짐수레(dolly), 핸드트럭(handtruck), 포크리프트(forklift), 또는 수작업으로) 버퍼 구역(205)으로 운반할 수 있다. 버퍼 구역(205)은, 예를 들면, 예측된 수요를 충족시키기 위해 픽업 구역에 그 아이템이 충분한 수량만큼 있기 때문에, 픽업 구역에서 현재 필요하지 않은 아이템에 대한 임시 저장 영역일 수 있다. 일부 실시예에서, 포크리프트(206)는 버퍼 구역(205) 주위와 인바운드 구역(203) 및 드롭 구역(207) 사이에서 아이템을 운반하도록 작동한다. (예를 들면, 예측된 수요로 인해) 픽업 구역에 아이템(202A, 202B)이 필요하면, 포크리프트는 아이템(202A, 202B)을 드롭 구역(207)으로 운반할 수 있다.
드롭 구역(207)은 픽업 구역(209)으로 운반되기 전에 아이템을 저장하는 FC(200)의 영역일 수 있다. 픽업 동작에 할당된 작업자("피커(picker)")는 픽업 구역의 아이템(202A, 202B)에 접근하고, 픽업 구역에 대한 바코드를 스캔하며, 모바일 디바이스(예를 들면, 디바이스(119B))를 사용하여 아이템(202A, 202B)과 관련된 바코드를 스캔할 수 있다. 그 다음 피커는 (예를 들면, 아이템을 카트에 놓거나 운반함으로써) 픽업 구역(209)에 아이템을 가져갈 수 있다.
픽업 구역(209)은 아이템(208)이 저장 유닛(210)에 저장되는 FC(200)의 영역일 수 있다. 일부 실시예에서, 저장 유닛(210)은 물리적 선반, 책꽂이, 박스, 토트(tote), 냉장고, 냉동고, 저온 저장고 등 중 하나 이상을 포함할 수 있다. 일부 실시예에서, 픽업 구역(209)은 다수의 플로어로 편성될 수 있다. 일부 실시예에서, 작업자 또는 기계는, 예를 들면, 포크리프트, 엘리베이터, 컨베이어 벨트, 카트, 핸드트럭, 짐수레, 자동화된 로봇 또는 디바이스, 또는 수작업을 포함하는 다양한 방식으로 아이템을 픽업 구역(209)으로 운반할 수 있다. 예를 들면, 피커는 아이템(202A, 202B)을 드롭 구역(207)의 핸드트럭 또는 카트에 놓을 수 있으며, 아이템(202A, 202B)을 픽업 구역(209)으로 가져갈 수 있다.
피커는 저장 유닛(210) 상의 특정 공간과 같은 픽업 구역(209)의 특정 스팟에 아이템을 배치(또는 "적재(stow)")하라는 명령을 수신할 수 있다. 예를 들면, 피커는 모바일 디바이스(예를 들면, 디바이스(119B))를 사용하여 아이템(202A)을 스캔할 수 있다. 디바이스는, 예를 들면, 통로, 선반 및 위치를 나타내는 시스템을 사용하여, 아이템(202A)을 적재해야 하는 위치를 나타낼 수 있다. 그 다음 디바이스는 그 위치에 아이템(202A)을 적재하기 전에 피커가 그 위치에서 바코드를 스캔하도록 할 수 있다. 디바이스는 도 1a의 WMS(119)와 같은 컴퓨터 시스템에 아이템(202A)이 디바이스(119B)를 사용하는 사용자에 의해 그 위치에 적재되었음을 나타내는 데이터를 (예를 들면, 무선 네트워크를 통해) 전송할 수 있다.
일단 사용자가 주문을 하면, 피커는 저장 유닛(210)으로부터 하나 이상의 아이템(208)을 검색하기 위해 디바이스(119B)로 명령을 수신할 수 있다. 피커는 아이템(208)을 검색하고, 아이템(208) 상의 바코드를 스캔하며, 운송 기구(214) 상에 놓을 수 있다. 일부 실시예에서, 운송 기구(214)가 슬라이드로서 표현되지만, 운송 기구는 컨베이어 벨트, 엘리베이터, 카트, 포크리프트, 핸드트럭, 짐수레, 카트 등 중 하나 이상으로서 구현될 수 있다. 그 다음 아이템(208)은 패킹 구역(211)에 도착할 수 있다.
패킹 구역(211)은 아이템이 픽업 구역(209)으로부터 수령되고 소비자에게 최종 배송하기 위해 박스 또는 가방에 패킹되는 FC(200)의 영역일 수 있다. 패킹 구역(211)에서, 아이템을 수령하도록 할당된 작업자("리빈 작업자(rebin worker)")는 픽업 구역(209)으로부터 아이템(208)을 수령하고, 그것이 어느 주문에 대응하는지를 결정할 것이다. 예를 들면, 리빈 작업자는 아이템(208) 상의 바코드를 스캔하기 위해 컴퓨터(119C)와 같은 디바이스를 사용할 수 있다. 컴퓨터(119C)는 아이템(208)이 어느 주문과 관련이 있는지를 시각적으로 나타낼 수 있다. 이는, 예를 들면, 주문에 대응하는 월(216) 상의 공간 또는 "셀(cell)"을 포함할 수 있다. (예를 들면, 셀이 주문의 모든 아이템을 포함하기 때문에) 일단 주문이 완료되면, 리빈 작업자는 패킹 작업자(또는 "패커(packer)")에게 주문이 완료된 것을 알릴 수 있다. 패커는 셀로부터 아이템을 검색하고, 배송을 위해 이들을 박스 또는 가방에 놓을 수 있다. 그 다음 패커는, 예를 들면, 포크리프트, 카트, 짐수레, 핸드트럭, 컨베이어 벨트, 수작업 또는 다른 방법을 통해, 박스 또는 가방을 허브 구역(213)으로 보낼 수 있다.
허브 구역(213)은 패킹 구역(211)으로부터 모든 박스 또는 가방("패키지(packages)")을 수신하는 FC(200)의 영역일 수 있다. 허브 구역(213)의 작업자 및/또는 기계는 패키지(218)를 검색하고, 각 패키지가 배달 영역의 어느 부분으로 배달되도록 되어 있는지를 결정하며, 패키지를 적합한 캠프 구역(215)으로 보낼 수 있다. 예를 들면, 배달 영역이 2개의 작은 하위 영역을 갖는다면, 패키지는 2개의 캠프 구역(215) 중 하나로 보내질 것이다. 일부 실시예에서, 작업자 또는 기계는 최종 목적지를 결정하기 위해 (예를 들면, 디바이스(119A-119C) 중 하나를 사용하여) 패키지를 스캔할 수 있다. 패키지를 캠프 구역(215)으로 보내는 것은, 예를 들면, (예를 들면, 우편 번호에 기초하여) 패키지가 향하는 지리적 영역의 부분을 결정하고, 지리적 영역의 부분과 관련된 캠프 구역(215)을 결정하는 것을 포함할 수 있다.
일부 실시예에서, 캠프 구역(215)은 루트(route) 및/또는 서브 루트로 분류하기 위해 허브 구역(213)으로부터 패키지가 수령되는 하나 이상의 빌딩, 하나 이상의 물리적 공간, 또는 하나 이상의 영역을 포함할 수 있다. 일부 실시예에서, 캠프 구역(215)은 FC(200)로부터 물리적으로 분리되어 있는 반면, 다른 실시예에서는 캠프 구역(215)은 FC(200)의 일부를 형성할 수 있다.
캠프 구역(215)의 작업자 및/또는 기계는, 예를 들면, 목적지와 기존 루트 및/또는 서브 루트의 비교, 각각의 루트 및/또는 서브 루트에 대한 작업부하의 계산, 하루 중 시각, 배송 방법, 패키지(220)를 배송하기 위한 비용, 패키지(220)의 아이템과 관련된 PDD 등에 기초하여 패키지(220)가 어느 루트 및/또는 서브 루트와 연관되어야 하는지를 결정할 수 있다. 일부 실시예에서, 작업자 또는 기계는 최종 목적지를 결정하기 위해 (예를 들면, 디바이스(119A-119C) 중 하나를 사용하여) 패키지를 스캔할 수 있다. 일단 패키지(220)가 특정 루트 및/또는 서브 루트에 할당되면, 작업자 및/또는 기계는 배송될 패키지(220)를 운반할 수 있다. 예시적인 도 2에서, 캠프 구역(215)은 트럭(222), 자동차(226), 및 배달원(224A, 224B)을 포함한다. 일부 실시예에서, 배달원(224A)이 트럭(222)을 운전할 수 있는데, 배달원(224A)은 FC(200)에 대한 패키지를 배달하는 풀-타임 직원이며, 트럭은 FC(200)를 소유, 임대 또는 운영하는 동일한 회사에 의해 소유, 임대, 또는 운행된다. 일부 실시예에서, 배달원(224B)이 자동차(226)를 운전할 수 있는데, 배달원(224B)은 필요에 따라(예를 들면, 계절에 따라) 배달하는 "플렉스(flex)" 또는 비상시적인 작업자이다. 자동차(226)는 배달원(224B)에 의해 소유, 임대 또는 운행될 수 있다.
도 3a는 인테이크(intake) 서브-시스템(300)의 예시적인 픽토그래픽(pictographic) 표시를 나타낸다. 인테이크 서브-시스템(300)은 소스 어플리케이션 프로그램 인터페이스(application program interface, API)(302)로부터의 통신의 초기 처리를 위해 지정될 수 있다. 소스 API(302)는 소비자, 배달원, 관리자, 및/또는 판매자가 사용하도록 특별히 구성된 다수의 API 중 임의의 하나일 수 있다. 소스 API(302)는 모바일 디바이스, 데스크톱 컴퓨터, 어댑터, 컨트롤러, 서버, 또는 API 통신을 송신 및/또는 수신할 수 있는 임의의 다른 디바이스와 같은 프로세서, 메모리 구성, 및/또는 통신 구성을 가지는 컴퓨팅 디바이스에 구현될 수 있다. 몇몇 실시예들에서, 인테이크 서브-시스템(300) 및/또는 인테이크 서브-시스템(300)의 구성은 (예를 들면, 도 3b-3d에 도시된 바와 같은) 다른 서브-시스템에 통신 가능하게 결합될 수 있다.
또한 인테이크 서브-시스템(300)은 소스 API(302)가 통신 가능하게 결합될 수 있는 다수의 엔드포인트 API(304)를 포함할 수 있다. 일부 실시예에서, 엔드포인트 API(304)는 유일한 하나의 엔드포인트 API일 수 있다. 엔드포인트 API(304)는 API 제공자(미도시)에 의해 관리될 수 있는 복수의 컨트롤러, 어댑터, 및/또는 다른 컴퓨팅 디바이스를 포함할 수 있다. 예를 들면, 엔드포인트 API(304)는 컨트롤러(306a), 컨트롤러(306b), 컨트롤러(306c), 컨트롤러(306d), 및/또는 컨트롤러(306e)와 같은 컨트롤러의 조합에 의해 구현될 수 있다. 일부 실시예에서, 컨트롤러는 특정 엔티티(예를 들면, 판매자)에 대한 동작을 취급하기 위해 지정될 수 있다. 컨트롤러는 서로 다른 엔티티 간(예를 들면, 소스 API(302)와 데이터 취합기(312) 간) 데이터흐름을 관리할 수 있는 하드웨어 디바이스 또는 소프트웨어 프로그램일 수 있다. 예를 들면, 컨트롤러는, 제한 없이, 플래시 컨트롤러, 어플리케이션 전달 컨트롤러, 주 영역 컨트롤러, 베이스보드 관리 컨트롤러, 및/또는 세션 경계 컨트롤러일 수 있다. 일부 실시예에서, 소스 API(302)로부터의 통신은 통신과 연관된 소스에 기초하여 특정 엔드포인트 API 또는 컨트롤러로 지향될 수 있다. 예를 들면, API 제공자는 소스 API(302)로부터 통신을 수신하고, (예를 들면, 메시지 식별자, IP 주소, MAC 주소, 통신 포맷, 및/또는 다른 고유 식별자에 기초하여) 통신의 소스 및/또는 유형을 결정할 수 있다. 식별된 통신 소스 및/또는 통신 유형에 기초하여, API 제공자는 특정 소스 및/또는 유형을 가지는 통신을 위해 구성될 수 있는 특정 컨트롤러에게 통신을 향하게 할 수 있다. 추가 예시로, API 제공자는 소스 API(302)로부터의 통신이 이것의 통신 소스로서 소비자 디바이스를 가지고 이것의 통신 유형으로서 반환 요청을 가지는 것으로 결정할 수 있고, 수신된 통신의 소스 및/또는 유형을 가지는 통신을 취급하도록 구성(예를 들면, 반환 요청 통신을 위해 구성)될 수 있는 엔드포인트 API(304)(예를 들면, 컨트롤러(306b))에게 통신을 향하게 할 수 있다.
또한 인테이크 서브-시스템(300)은 소스 API(302)로부터의 통신을 검증할 수 있고, 엔드포인트 API(304)에 통신 가능하게 결합될 수 있는 검증기(308)를 포함할 수 있다. 검증기(308)는 엔드포인트 API(304) 내부(예를 들면, 컨트롤러의 일부로서)에 존재할 수 있거나, 또는 엔드포인트 API(304)가 연결될 수 있는 서버와 같은 별개의 구성으로 존재할 수 있다. 검증기(308)는 검증 프로세스(예를 들면, 소스 API(302)로부터 수신된 통신을 검증하는 프로세스)를 수행하도록 구성된 다양한 구성(예를 들면, 모듈, 디바이스, 프로세서, 등)을 포함할 수 있다. 예를 들면, 검증기(308)는 검증기 호출부, (예를 들면, 통신으로부터의 데이터를 재포맷하기 위한) 검증 전처리부, (예를 들면, 데이터에 대한 검증 동작을 수행하기 위한) 검증기 프로세서, (예를 들면, 검증된 데이터를 도 3c의 규칙 엔진(362)과 같은 다른 엔티티에 의해 해석 가능한 포맷으로 재포맷하기 위한) 검증기 후처리부, 검증 관리부, 및/또는 (다른 서브-시스템으로 메시지를 향하게 할 수 있는) 메시지 퍼블리셔를 포함할 수 있다.
또한 인테이크 서브-시스템(300)은 검증기(308)가 통신 가능하게 결합될 수 있는 예외 핸들러(310)를 포함할 수 있다. 예외 핸들러(310)는 검증기(308)의 일부일 수 있거나, 서버 또는 모바일 디바이스와 같은 별개의 디바이스 또는 구성일 수 있다. 일부 실시예에서, 검증기(308)는 검증기(308)에 의해 결정되었을 수 있는 통신의 검증 결과에 기초하여 통신을 예외 핸들러(310)로 향하게 할 수 있다. 예를 들면, 통신이 검증기(308)에 의해 구현된 적어도 하나의 규칙 또는 알고리즘에 따르지 않으면, 검증기는 통신을 예외 핸들러(310)에게 향하게 할 수 있다. 일부 실시예에서, 예외 핸들러(310)는 통신에 의해 부합되지 아니한 적어도 하나의 규칙 또는 알고리즘에 기반하여 통신으로부터의 정보를 재포맷, 분할, 파스(parse), 태그, 및/또는 다른 방법으로 재구성 또는 전송(예를 들면, 관리자 디바이스에게 경보를 발행함)하도록 구성될 수 있다. 예외 핸들러(310)는 데이터 취합기(312) 및/또는 기록 및 추적 모듈(314)에 통신 가능하게 결합될 수 있다.
또한 인테이크 서브-시스템(300)은 엔드포인트 API(304), 예외 핸들러(310), 및/또는 기록 및 추적 모듈(314)과 같은 서로 다른 소스들로부터의 데이터를 취합할 수 있는 데이터 취합기(312)를 포함할 수 있다. 데이터 취합기(312)는 서브-시스템(300)의 구성과 서브-시스템(도 3b의 325, 도 3c의 355, 및 도 3d의 375)을 포함하는 다른 시스템의 디바이스 및/또는 구성뿐만 아니라, 임의의 디바이스 및/또는 서브-시스템(300)의 구성과 통신 가능하게 결합될 수 있다. 데이터 취합기(312)는 다른 목적을 가지는 디바이스(예를 들면, 검증기(308))의 일부일 수 있고, 또는 서버 또는 모바일 디바이스와 같은 별개의 디바이스 또는 구성일 수 있다. 일부 실시예에서, 데이터 취합기(312)는 데이터 취합 프로세스(예를 들면, 소스 API(302) 및/또는 예외 핸들러(310)와 같은 소스로부터의 데이터를 취합 및/또는 분석하는 프로세스)를 수행하도록 구성된 다양한 구성들(예를 들면, 모듈, 디바이스, 프로세서, 등)을 포함할 수 있다. 예를 들면, 데이터 취합기(312)는 데이터 캐싱 구성, 데이터 취합 구성, 데이터 변환 구성, 데이터 맵핑 구성, 및/또는 서비스 라우터를 포함할 수 있다.
또한 인테이크 서브-시스템(300)은 통신(예를 들면, API 소스(302)로부터의 통신)과 연관된 데이터를 기록 및/또는 추적할 수 있는 기록 및 추적 모듈(314)을 포함할 수 있다. 기록 및 추적 모듈(314)은 다른 목적을 가지는 디바이스(예를 들면, 데이터 취합기(312))의 일부일 수 있고, 또는 서버 또는 모바일 디바이스와 같은 별개의 디바이스 또는 구성일 수 있다. 기록 및 추적 모듈(314)은 데이터 취합 프로세스(예를 들면, 소스 API(302) 및/또는 예외 핸들러(310)와 같은 소스로부터의 데이터를 추적 및/또는 기록하는 프로세스)를 수행하도록 구성된 다양한 구성들(예를 들면, 모듈, 디바이스, 프로세서, 등)을 포함할 수 있다. 예를 들면, 기록 및 추적 모듈(314)은 추적기(316) 및/또는 추적 분석기(318)를 포함할 수 있다.
추적기(316)는 API 소스(302), 검증기(308) 등으로부터의 통신과 연관된 데이터와 같은 데이터를 추적하는 기능을 수행할 수 있다. 일부 실시예에서, 추적기(316)는 통신과 연관된 데이터에 추적 식별자 및/또는 스팬(span) 식별자를 추가하도록 구성될 수 있다. 일부 실시예에서, 추적기(316)는 추적 및/또는 기록 데이터를 어디로 송신할지, 추적 및/또는 기록을 보관할 임계 횟수, 데이터 포맷, 전송할 식별자의 특정 조합, 및/또는 추적할 특정 라이브러리에 대한 정의와 같은 기록 및 추적에 대한 정의(예를 들면, 사용자-정의, 머신-정의, 및/또는 사용자-정의와 머신-정의의 조합)을 유지할 수 있다. 일부 실시예에서, 추적기(316)는 Spring Cloud Sleuth와 같은 기능 제공자의 양상을 구현할 수 있다.
추적 분석기(318)는 디바이스(예를 들면, 소스 API(302)를 구현하는 디바이스)로부터의 통신과 연관될 수 있는 추적 데이터 및/또는 기록 데이터와 같은 데이터를 분석하는 기능을 수행할 수 있다. 예를 들면, 추적 분석기(318)는 타이밍 데이터(예를 들면, 예외가 발생한 시간, 예외의 빈도 등), 태그, 규칙 실패 데이터, 규칙 만족 데이터, 디바이스 식별자, 메시지 식별자, 및/또는 소스 API(302)와 연관된 임의 데이터를 취합할 수 있다. 일부 실시예에서, 추적 분석기(318)는 추적 및/또는 로그 데이터의 시각적 표현(예를 들면, 필터링 가능한 데이터의 차트, 선도(line diagram), 통계 및/또는 머신 학습 알고리즘에 의해 생성된 추천 등)을 생성할 수 있다. 일부 실시예에서, 추적 분석기(318)는 Zipkin과 같은 기능 제공자의 양상을 구현할 수 있다.
도 3b는 출력 서브-시스템(325)의 예시적인 픽토그래픽 표시를 나타낸다. 출력 서브-시스템(325)은 도 3d의 작업 흐름 서브-시스템(375)의 출력을 처리하기 위해 지정될 수 있다. 출력 서브-시스템(325)은 도 3c의 외부 데이터 소스(370)로 처리된 출력을 전달하고, 도 3a의 기록 및 추적 모듈(314) 및/또는 하나 이상의 외부 서비스(339a-e)를 이용하여 기록 및/또는 추적되도록 처리된 출력을 전달할 수 있다. 출력 서브-시스템(325)은 소비자, 배달원, 관리자, 및/또는 판매자가 사용하도록 특별히 구성될 수 있다. 출력 서브-시스템(325)은 프로세서, 메모리 구성, 및/또는 통신 구성을 가지는 컴퓨팅 디바이스에 구현될 수 있다. 일부 실시예에서, 출력 서브-시스템(325) 및/또는 출력 서브-시스템(325)의 구성은 (예를 들면, 도 3a-3d에서 도시된 바와 같은) 다른 서브-시스템에 통신 가능하게 결합될 수 있다.
출력 서브-시스템(325)은 도 3d의 작업 흐름 서브-시스템(375)에 통신 가능하게 결합될 수 있는 다수의 Creturns Domains 모듈(327)을 포함할 수 있다. 일부 실시예에서, Creturns Domains 모듈(327)은 다양한 서비스(329a-d)를 포함할 수 있다. 도 3b에 나타난 바와 같은 서비스의 예는 취소 서비스(329a), 반환 서비스(329b), 교환 서비스(329c), 및/또는 양해(concession) 서비스(329d)를 포함할 수 있다. 각 서비스(329a-d)는 도 3d의 작업 흐름 서브-시스템(375)의 각각의 작업 흐름 태스크로부터의 출력 처리를 담당할 수 있다. 예를 들면, 도 3d의 취소 프로세스 작업 흐름(383a)은 출력을 취소 서비스(329a)에 전달할 수 있는 반면, 리턴 프로세스 작업 흐름(383b)은 출력을 반환 서비스(329b)에 전달할 수 있다. Creturns Domains 모듈(327)의 아키텍쳐(architecture)는 필요한 추가 서비스를 추가하도록 변형될 수 있다.
Creturns Domains 모듈(327)은 도 3a의 기록 및 추적 모듈(314) 및/또는 외부 서비스 프록시 모듈(331)을 이용하여 기록하고 추적하면서, 처리된 정보를 도 3c의 외부 데이터 소스(370)에게 전달할 수 있다. 외부 데이터 소스(370)에게 전달된 정보는 도 3c를 참조한 부분에서 설명되는 바와 같이 저장된다. 기록 및 추적 모듈(314)로 전달된 정보는 도 3a를 참조한 부분에서 상술된 바와 같이 기록되고 처리된다.
외부 서비스 프록시 모듈(331)은, 출력 서브-시스템(325)의 일부이고, 적절한 외부 서비스(339a-339e)로의 추가 지시를 위해 Creturns Domains 모듈(327)로부터의 처리된 출력을 수신할 수 있다. 출력 서브-시스템(325)은 한 번 이상 서비스 프록시를 초기화하기 위해 요구되는 시간과 컴퓨팅 자원의 소모 없이 동일한 서비스를 반복적으로 연결하기 위해 외부 서비스 프록시 모듈(331)을 이용할 수 있다. 외부 서비스 프록시 모듈(331)은 Creturns Domains 모듈(327)과 외부 서비스(339a-339e) 간의 소프트웨어 또는 하드웨어 시스템으로 구현될 수 있다. 외부 서비스 프록시 모듈(331)은 출력 서브-시스템(325)과 같은 동일한 머신에 또는 별개의 서버에 존재할 수 있다. 외부 서비스 프록시 모듈(331)은 소비자, 관리자, 및/또는 판매자가 사용하도록 특별히 구성될 수 있다. 외부 서비스 프록시 모듈(331)은 프로세서, 메모리 구성, 및/또는 통신 구성을 가지는 컴퓨팅 디바이스에 구현될 수 있다.
또한 외부 서비스 프록시 모듈(331)은 도 3d의 Crenturn WorkflowStarter(381)로부터 직접적으로 데이터를 수신할 수 있고 도 3d의 작업 흐름 서브-시스템(375)에 통신 가능하게 결합될 수 있는 외부 서비스 작업부(333)를 포함할 수 있다. 외부 서비스 작업부(333)는 외부 서비스 프록시 모듈(331) 내에 존재하거나 외부 서비스 프록시 모듈(331)이 연결될 수 있는 서버와 같은 별개의 구성으로 존재할 수 있다. 외부 서비스 작업부(333)는 출력 처리를 수행하도록 구성된 다양한 구성(예를 들면, 모듈, 디바이스, 프로세서 등)을 포함할 수 있다. 예를 들면, 외부 서비스 작업부(333)는 Crenturns Domains 모듈(327)에 의해 처리되지 않는 데이터를 처리할 수 있다.
또한 외부 서비스 프록시 모듈(331)은 외부 서비스 프록시 모듈(331)이 통신 가능하게 결합될 수 있는 외부 API 요청부(335)를 포함할 수 있다. 외부 API 요청부(335)는 외부 서비스 프록시 모듈(331)의 일부이거나, 또는 서버 또는 가상 인스턴스(instance)와 같은 별개의 디바이스 또는 구성일 수 있다. 일부 실시예에서, 외부 서비스 프록시 모듈(331)은 외부 서비스(339a-e) 중 어느 외부 서비스에게 출력의 전달이 요구되는지에 기초하여 외부 API 요청부(335)로의 직접 통신을 가질 수 있으며, 이러한 외부 서비스는 Creturns Domains 모듈(327) 또는 외부 서비스 작업부(333)에 의해 결정되었던 것일 수 있다. 예를 들어, 외부 서비스가 통신을 위해 API를 요구하면, 외부 API 요청부(335)는 요구되는 외부 서비스와 연결을 수립하기 위해 적절한 API 정보를 요청할 수 있다. 일부 실시예에서, 외부 API 요청부(335)는 외부 서비스에 의해 이용되는 적어도 하나의 규칙 또는 알고리즘에 기초하여 통신으로부터의 정보를 재포맷, 분할, 파스, 태그, 및/또는 다른 방법으로 재구성 또는 전송할 수 있다.
또한 외부 서비스 프록시 모듈(331)은 외부 서비스 작업부(333)가 통신 가능하게 결합될 수 있는 생산부(337)를 포함할 수 있다. 생산부(337)는 외부 서비스 프록시 모듈(331)의 일부일 수 있거나, 또는 서버 또는 가상 인스턴스와 같은 별개의 디바이스 또는 구성일 수 있다. 생산부(337)는 메시지를 토픽에 퍼블리시하는 데 이용될 수 있다. 토픽은 메시지를 포함하는 다수의 파티션으로 나뉠 수 있다. 파티션 내의 각 메시지는 그것의 고유 오프셋에 의해 할당 및 식별된다. 메시지 그 자체가 어느 토픽과 파티션에 퍼블리시할 지에 대한 정보를 포함하므로 데이터는 동일한 생산부를 이용하여 서로 다른 토픽에 퍼블리시될 수 있다. 일부 실시예에서, 생산부(337)는 Kafka를 이용하여 구현될 수 있다.
외부 서비스 프록시 모듈(331)은 처리된 정보를 도 3a의 기록 및 추적 모듈(314) 및/또는 외부 서비스(339a-e)로 전달할 수 있다. 기록 및 추적 모듈(314)로 전달된 정보는 도 3a를 참조한 부분에서 앞서 설명된 바와 같이 기록되고 처리된다. 외부 서비스(339a-e)는 요청에 기반하여 활동을 개시한다. 도 3b에 나타낸 바와 같은 서비스의 예는 주문 서비스(339a), 풀필먼트(fulfillment) 서비스(339b), 배송 서비스(339c), 베네핏(benfit) 서비스(339d) 및/또는 티켓 서비스(339e)를 포함할 수 있다. 각 서비스(329a-d)는 특정 동작을 담당할 수 있다. 예를 들어, 이벤트에서, 도 3d의 작업 흐름 서브-시스템(375)은 교환 서비스(329c)가 처리하도록 출력을 전달하여, 다수의 외부 서비스를 개시할 수 있다. 아이템의 교환은 새로운 아이템을 주문(주문 명령어는 공급자로부터 아이템을 구입하고, 피커(picker)에게 아이템을 준비할 것을 알리고, 아이템을 온라인으로 구매하고, 제3자 스토어로 이동하고 및 그것을 찾아가라는 명령어, 또는 아이템을 획득하는 것으로 지시되는 다른 명령어를 포함할 수 있다)하기 위한 주문 서비스(339a)로의 출력, 반환 배송표를 생성하기 위한 배송 서비스(339c)로의 출력, 및/또는 반환된 아이템을 처리하기 위한 풀필먼트 서비스(339b)로의 출력을 수반할 수 있다. 출력 서브-시스템(325)의 아키텍쳐는 필요에 따라서 추가 외부 서비스가 추가되도록 수정될 수 있다.
도 3c는 개시된 실시에 따른, 예시적인 제어 서브-시스템(350), 예시적인 반환 이벤트스토어(361), 예시적인 규칙 엔진(362), 및 예시적인 외부 데이터 소스(370)의 픽토그래픽 표시(355)를 나타낸다.
제어 서브-시스템(350)은 시스템(도 3a의 300, 도 3b의 325, 및 도 3d의 375)의 다양한 구성에 의해 이용되는 데이터를 생성, 갱신, 유지, 및/또는 관리하도록 구성될 수 있다. 예를 들면, 제어 서브-시스템(350)은 소비자에 의한 반환을 관리하기 위한 파라미터(예를 들면, 소비자에 의한 반환을 승인하고 거절하기 위한 규칙), 반환을 처리하기 위한 작업 흐름을 관리하기 위한 파라미터, 및/또는 특정 반환 이벤트를 저장하기 위한 파라미터를 생성, 갱신, 및/또는 수정하도록 구성될 수 있다.
도 3c에 나타낸 바와 같이, 제어 서브-시스템(350)은 규칙 관리 모듈(351), 이벤트 관리 모듈(352), 및 작업 흐름 관리 모듈(353)을 포함할 수 있다.
규칙 관리 모듈(351)은 소비자에 의한 반환을 처리하기 위한 규칙을 관리하도록 구성될 수 있다. 예를 들면, 규칙 관리 모듈(351)은 소비자에 의한 반환 요청을 거절하기 위한 규칙을 생성 및/또는 수정하도록 구성될 수 있다. 예시로, 규칙 관리 모듈(351)은, 예를 들면, 소비자의 이전 반환(들)에 대한 데이터, 반환 요청에 관여된 통화량(monetary amount), 반환될 재화의 유형 등을 포함하는 다양한 파라미터에 기초하여 소비자에 의한 반환 요청을 거절하기 위한 규칙을 생성 및/또는 수정하도록 구성될 수 있다. 예를 들면, 소비자가 과거에 사전 결정된 일수(예를 들면, 180일) 이내에 반환을 위해 빈(또는 부분적으로 빈) 박스를 반환한 경우, 이는 소비자가 시스템을 속이려고 시도했음을 나타낼 수 있고, 규칙 관리 모듈(351)은 소비자의 반환 요청을 거절하기 위한 규칙을 생성할 수 있다.
일부 실시예에서, 규칙 관리 모듈(351)은 제어 서브-시스템(350)의 사용자에 의한 입력에 기초하여 규칙을 생성 및/또는 수정하도록 구성될 수 있다. 예를 들면, 규칙 관리 모듈(351)은 사용자로부터 반환 요청을 검증하기 위한 규칙의 하나 이상의 파라미터를 수정하고 그리고 그에 따라 규칙의 파라미터(들)을 수정하기 위한 입력을 수신할 수 있다.
이벤트 관리 모듈(352)은 반환 이벤트스토어(361)에 저장된 이벤트를 생성, 수정, 및/또는 관리하도록 구성될 수 있다. 예를 들면, 이벤트 관리 모듈(352)은 소비자 또는 시스템에 의해 개시된 반환 요청에 대한 일련의 이벤트를 생성하고 이벤트를 반환 이벤트스토어(361)에 저장할 수 있다. 예로서, 소비자는 소비자와 연관된 사용자 디바이스를 통해 주문의 반환을 개시할 수 있다. 이벤트 관리 모듈(352)은 반환 요청을 수신하는 이벤트를 생성하고 이벤트를 반환 이벤트스토어(361)에 저장할 수 있다. 일부 실시예에서, 이벤트는 반환, 소비자, 및 반환과 관련된 주문에 대한 정보를 포함할 수 있다. 예를 들면, 이벤트 관리 모듈(352)은 소비자에 의해 요청된 반환에 대한 제1 이벤트를 생성할 수 있고, 이는 반환 요청의 정보, 반환 요청을 수신한 타임 스탬프, 소비자에 대한 정보, 또는 그 밖의 유사한 것, 또는 이들의 조합을 포함할 수 있다. 이벤트 관리 모듈(352)은 반환 대상인 하나 이상의 아이템이 소비자로부터 수신될 때, 제2 이벤트를 생성할 수 있고, 이는 아이템(들) 수신에 대한 정보(예를 들면, 수량, 상태, 등), 아이템(들)의 수신 타임 스탬프, 등을 포함할 수 있다. 또한 이벤트 관리 모듈(352)은 제1 및 제2 이벤트를 반환 이벤트스토어(361)에 반환에 대한 일련의 이벤트로 저장할 수 있다.
일부 실시예에서, 반환 이벤트스토어(361)는 예를 들면, Oracle™ 데이터베이스, Sybase™ 데이터베이스, 또는 다른 관계형 데이터베이스 또는 Hadoop™ 시퀀스 파일, HBase™, 또는 Cassandra™와 같은 비-관계형 데이터베이스를 포함할 수 있다. 반환 이벤트스토어(361)는 HBase, MongoDB™ 또는 Cassandra™와 같은 NoSQL 데이터베이스를 포함할 수 있다. 선택적으로, 데이터베이스(320)는 Oracle, MySQL 및 Microsoft SQL 서버와 같은 관계형 데이터베이스를 포함할 수 있다. 일부 실시예에서, 반환 이벤트스토어(361)는 서버, 범용 컴퓨터, 메인프레임 컴퓨터, 또는 이들 구성의 임의 조합의 형태를 취할 수 있다.
작업 흐름 관리 모듈(353)은 시스템(도 3a의 300, 도 3b의 325, 도 3d의 375)의 다양한 구성에 의해 이용되는 작업 흐름을 생성, 수정, 및/또는 관리할 수 있다. 예를 들면, 작업 흐름 관리 모듈(353)은 작업 흐름 서브-시스템(375)(도 3d에 나타냄)에 의해 이용되는 취소 프로세스(383a), 반환 프로세스(383b), 교환 프로세스(383c), 배송 추적(383d), 수집 프로세스(383e), 환불 프로세스(383f), 및 철회(withdraw) 프로세스(383g)를 생성, 수정, 및/또는 관리하도록 구성될 수 있다.
일부 실시예에서, 제어 서브-시스템(350)은 Creturns Domains 모듈(327)(도 3b에 나타냄)에 의해 이용되는 서비스를 생성, 수정, 및/또는 관리하도록 구성될 수 있다. 예를 들면, 제어 서브-시스템(350)은 취소 서비스(329a), 반환 서비스(329b), 교환 서비스(329c), 및/또는 양해 서비스(329d)를 생성, 수정, 및/또는 관리하도록 구성될 수 있다. Creturns Domains 모듈(327)은 제어 서브-시스템(350)으로부터 하나 이상의 서비스를 획득할 수 있다.
규칙 엔진(362)은 제어 서브-시스템(350)으로부터의 반환을 처리하기 위한 규칙을 획득하고, 도 3d의 작업 흐름 서브-시스템(375)의 다른 구성들에 대한 규칙을 저장 및/또는 관리하도록 구성될 수 있다. 예를 들면, 도 3d의 작업 흐름 서브-시스템(375)은 규칙 엔진(362)으로부터의 반환 요청을 검증하기 위한 규칙을 획득하도록 구성될 수 있다. 일부 실시예에서, 규칙 엔진(362)은 반환을 관리 및/또는 처리하는 규칙을 저장하기 위한 규칙 데이터베이스(363)를 포함할 수 있다.
외부 데이터 소스(370)는 서브시스템(도 3a의 300, 도 3b의 325, 및 도 3d의 375)을 포함하는 시스템의 다양한 구성에 대한 데이터를 저장하도록 구성될 수 있다. 예를 들면, 외부 데이터 소스(370)는, 예를 들어 취소 서비스329a), 반환 서비스(329b), 교환 서비스(329c), 및/또는 양해 서비스(329d)를 포함하는 제어 서브-시스템(350)에 의해 생성 및/또는 갱신되는 다양한 서비스를 저장할 수 있다. Creturns Domains 모듈(327)은 외부 데이터 소스(370)로부터의 하나 이상의 서비스를 획득할 수 있다.
다른 예로서, 외부 데이터 소스(370)는 이벤트(예를 들면, 반환 이벤트)에 대한 데이터를 저장하도록 구성된 이벤트스토어(371)를 포함할 수 있다. 일부 실시예에서, 이벤트스토어(371)는 쓰기(write) 명령에 응답하여 데이터를 쓰도록 구성된 쓰기 데이터베이스(372)를 포함할 수 있다. 이벤트스토어는 질의 명령에 응답하여서만 데이터를 읽도록 구성된 하나 이상의 읽기 데이터베이스(373)(예를 들면, 읽기 데이터베이스(373A), 읽기 데이터베이스(373B) 등)를 포함할 수 있다. 일부 실시예에서, 읽기 데이터베이스(373)는 쓰기 데이터베이스(372)에 포함된 데이터와 동일한 데이터를 포함할 수 있다. 예를 들면, 쓰기 데이터베이스(372)에 저장된 데이터가 쓰기 명령에 응답하여 갱신되면, 쓰기 데이터베이스(373)와 읽기 데이터베이스(373)가 동일한 데이터를 포함하도록 읽기 데이터베이스(373)의 대응하는 데이터가 그에 맞춰 갱신될 수 있다. 일부 실시예에서, 외부 데이터 소스(370)는 제어 서브-시스템(350)에 대한 관리(administration) 데이터를 저장하도록 구성된 관리(admin) 데이터베이스(374)를 포함할 수 있다.
일부 실시예에서, 이벤트스토어(371) 및/또는 관리 데이터베이스(374)는, 예를 들면, Oracle™ 데이터베이스, Sybase™ 데이터베이스, 또는 다른 관계형 데이터베이스 또는 Hadoop™ 시퀀스 파일, HBase™, 또는 Cassandra™와 같은 비-관계형 데이터베이스를 포함할 수 있다. 이벤트스토어(371) 및/또는 관리 데이터베이스(374)는 HBase, MongoDB™ 또는 Cassandra™와 같은 NoSQL 데이터베이스를 포함할 수 있다. 선택적으로, 데이터베이스(320)는 Oracle, MySQL 및 Microsoft SQL 서버와 같은 관계형 데이터베이스를 포함할 수 있다. 일부 실시예에서, 이벤트스토어(371) 및/또는 관리 데이터베이스(374)는 서버, 범용 컴퓨터, 메인프레임 컴퓨터, 또는 이들 구성의 임의 조합의 형태를 취할 수 있다.
도 3d는 작업 흐름 서브-시스템(375)의 예시적인 픽토그래픽 표시를 나타낸다. 작업 흐름 서브-시스템(375)은 인테이크 서브-시스템(300)의 출력을 처리하기 위해 지정될 수 있다. 작업 흐름 서브-시스템(375)은 검증기(308) 출력을 출력 서브-시스템(325)으로 전달할 수 있다. 작업 흐름 서브-시스템(375)은 소비자, 배달원, 관리자, 및/또는 판매자가 사용하도록 특별히 구성될 수 있다. 작업 흐름 서브-시스템(375)은 프로세서, 메모리 구성, 및/또는 통신 구성을 가지는 컴퓨팅 디바이스에 구현될 수 있다. 일부 실시예에서, 작업 흐름 서브-시스템(375) 및/또는 작업 흐름 서브-시스템(375)의 구성은 (예를 들면, 도 3a-3d에 나타낸 바와 같은) 다른 서브 시스템에 통신 가능하게 결합될 수 있다.
작업 흐름 서브-시스템(375)은 프레임워크 모듈(377)을 포함할 수 있다. 프레임워크 모듈(377)은 Spring WebFlux 또는 유사한 기술을 활용할 수 있다. 프레임워크 모듈(377)은 적은 수의 쓰레드 및 더 적은 하드웨어 자원의 규모로 동시 실행(concurrency)을 취급하는 비-차단 웹 스택을 제공할 수 있다. 프레임워크 모듈(377)은 다양한 프로그래밍 모듈을 포함할 수 있다. 도 3d에 나타낸 바와 같은 모듈의 예는 반환 모듈(379a), 교환 모듈(379b), 및 취소 모듈(379c)을 포함할 수 있다. 모듈(379a-c)은 소매, 제3자, 및 티켓 할인(ticket offers)을 위한 처리 로직을 포함할 수 있다. 또한 모듈(379a-c)은 각각의 데이터를 관리하는 서브-시스템과 통신하기 위한 API를 포함할 수 있다.
또한 작업 흐름 서브-시스템(375)은 프레임워크 모듈(377)에 통신 가능하게 결합될 수 있는 WorkflowStarter(381)를 포함할 수 있다. WorkflowStarter(381)는 프레임워크 모듈(377)로부터 수신된 입력에 기초하여 작업 흐름을 개시할 수 있는 프로세스(383a-g)의 목록을 포함할 수 있다. 도 3d에 나타낸 바와 같은 프로세스의 예는 취소 프로세스(383a)(소비자, 공급자, 또는 다른 주문 취급자에 의한 주문의 취소에 의해 개시되는 작업 흐름을 시작하기 위한 명령어를 포함함), 반환 프로세스(383b)(소비자, 공급자, 또는 다른 주문 취급자에 의해 반환된 전부 또는 일부 주문에 의해 개시되는 작업 흐름을 시작하기 위한 명령어를 포함함), 교환 프로세스(383c)(소비자, 공급자, 또는 다른 주문 취급자에 의해 시작된 전부 또는 일부 주문의 교환에 의해 개시되는 작업 흐름을 시작하기 위한 명령어를 포함함), 배송 추적(383d)(소비자, 공급자, 또는 다른 주문 취급자에 의한 전부 또는 일부 주문의 배송 상태 추적 요청에 의해 개시되는 작업 흐름을 시작하기 위한 명령어를 포함함), 수집 프로세스(383e)(소비자, 공급자, 또는 다른 주문 취급자에 의한 전부 또는 일부 주문의 정보 추적 요청에 의해 개시되는 작업 흐름을 시작하기 위한 명령어를 포함함), 환불 프로세스(383f)(소비자, 공급자, 또는 다른 주문 취급자에 의해 시작된 전부 또는 일부 주문에 대한 환불 요청에 의해 개시되는 작업 흐름을 시작하기 위한 명령어를 포함함), 및 철회 프로세스(383g)(소비자, 공급자, 또는 다른 주문 취급자에 의해 시작된 전부 또는 일부 주문의 철회에 의해 개시되는 작업 흐름을 시작하기 위한 명령어를 포함함)를 포함할 수 있다.
또한 작업 흐름 서브-시스템(375)은 작업 흐름 모델러(393) 및 모델 저장소(395)를 포함할 수 있다. 작업 흐름 모델러(393)는 사용자 입력에 기초하여 작업 흐름을 생성하거나 수정할 수 있다. 작업 흐름의 예시들은 도 5-23에서 더 개시된다. 또한 작업 흐름 모델러(393)는 Creturn Domains 모듈(329a-d) 중 하나가 작업 흐름을 실행하는 동안 발생할 수 있는 오류를 포착하기 위해 Creturn Domains(327) 및 BPM 엔진(391)과 통신하여 태스크(task)의 흐름이 작업 흐름 내에서 적절하게 정의되었는지 확인할 수 있다. 어떤 모듈이 결합되는지에 대한 선택은 BPM 엔진(391)의 구성에 기초할 수 있다. 실행/런타임(runtime) 중에, 작업 흐름 모델러(393)는 각 태스크를 실행하는데 사용되는 Creturn Domains(327)가 연결되어 있는지 여부와 오류가 있는지를 결정하기 위해 BPM 엔진(391)과 통신한다. 게다가, WorkflowStarter(381)는 BPM 엔진(391)을 사용하여 오류 메시지의 사본 및 입력 값을 수신하고, 이를 사용자에게 전달할 수 있다. 작업 흐름이 검증된 후에, 예를 들어 본 개시에 따른 실행 또는 추가 수정을 위해, 이는 작업 흐름 서브-시스템(375)에 의한 향후 액세스를 위해 모델 저장소(395)에 저장될 수 있다.
게다가, 프레임워크 모듈(377)의 각 프로그래밍 모듈(379a-c)은 복수의 프로세스(383a-g)를 개시할 수 있다. 예를 들면, 취소 모듈(379c)은 취소된 아이템이 배송되었는지 또는 여전히 배달원이 소유하고 있는지를 결정하기 위해 배송 추적 프로세스(383d)를 개시할 수 있다. 또한 동일한 취소 모듈(379c)은 소비자에게 환불하기 위해 환불 프로세스(383f)를 개시할 수 있다.
다양한 조합이 프로그램될 수 있고 그리고 소비자, 배달원, 관리자, 및/또는 판매자가 사용하도록 특별히 구성될 수 있다. WorkflowStarter(381)는 프로세서, 메모리 구성, 및/또는 통신 구성을 가지는 컴퓨팅 디바이스에 구현될 수 있다. 일부 실시예에서, WorkflowStarter(381) 및/또는 WorkflowStarter(381)의 구성은 (예를 들면, 도 3d에 나타낸 바와 같은) 작업 흐름 서브-시스템(375)의 다른 일부에 통신 가능하게 결합될 수 있다. 게다가, 작업 흐름 서브-시스템(375)의 아키텍쳐는 필요에 따라서 추가적인 처리와 프로그램 모듈을 추가하도록 수정된다.
또한 작업 흐름 서브-시스템(375)은 WorkflowStarter(381)와 출력 서브-시스템(325)과 통신 가능하게 결합될 수 있는 작업 흐름 서비스 모듈(385)을 포함할 수 있다. 작업 흐름 서비스 모듈(385)은 작업 흐름 제어 및 설계를 위해 지정될 수 있다. 작업 흐름 서비스 모듈(385)은 Creturn 작업 흐름 서비스 모듈(387) 및 작업 흐름 오케스트레이션(orchestration) 모듈(391)을 포함할 수 있다. 작업 흐름 서비스 모듈(385)은 출력 서브-시스템(325)에 의한 처리를 위해 출력을 제공할 수 있다.
Creturn 작업 흐름 서비스 모듈(387)은 WorkflowStarter(381)로부터 수신된 입력에 기초하여 작업 흐름을 제어할 수 있는 다수의 서브-모듈(389a-b)을 포함할 수 있다. 도 3d에 나타낸 바와 같은 처리의 예는 소매 아이템의 반환에 대한 작업 흐름의 설계 및/또는 제어를 허용하는 소매 반환 서브-모듈(389a) 및 제3자 아이템의 반환에 대한 작업 흐름의 설계 및/또는 제어를 허용하는 제3자 반환 서브-모듈(389b)을 포함할 수 있다. Creturn 작업 흐름 서비스 모듈(387)의 아키텍쳐는 필요에 따라서 추가적인 서브- 모듈을 추가하도록 수정된다. Creturn 작업 흐름 서비스 모듈(387) 내의 작업 흐름은 소비자, 배달원, 관리자 및/또는 판매자에 의해 제어 및/또는 설계될 수 있다. Creturn 작업 흐름 서비스 모듈(387)은 프로세서, 메모리 구성, 및/또는 통신 구성을 가지는 컴퓨팅 디바이스에 구현될 수 있고 그리고 작업 흐름 서브-시스템(375)의 다른 일부에 통신 가능하게 결합될 수 있다.
작업 흐름 오케스트레이션 모듈(391)은 소비자, 배달원, 관리자, 및/또는 판매자에 의해 접근될 수 있는 작업 흐름 제어 세트를 포함할 수 있다. 작업 흐름 오케스트레이션 모듈(391)은 비즈니스 처리 관리(business process management, BPM) 엔진과 지원 프레임워크를 이용하여 구현될 수 있고, 이의 일 예는 Activiti와 Spring Boot/Docker일 수 있다. 작업 흐름 오케스트레이션 모듈(391) 엔진은 사람 태스크와 서비스 호출로 구성된 프로세스 정의를 내리고 이들을 특정한 순서로 실행하는 것을 핵심 목표로 하며, 정의에 대한 프로세스 인스턴스에 관한 데이터를 시작, 관리 및 질의하기 위한 다양한 API를 공개할 수 있다. 작업 흐름 오케스트레이션 모듈(391)은 프로세서, 메모리 구성, 및/또는 통신 구성을 가지는 컴퓨팅 디바이스에 구현될 수 있다. 작업 흐름 오케스트레이션 모듈(391)은 작업 흐름 서브-시스템(375)의 다른 일부에 통신 가능하게 결합될 수 있다.
도 4는 개시된 실시예에 따른, 작업 흐름 서브-시스템(375)에 의해 수행되는 작업 흐름 편집에 대한 예시적인 프로세스(400)의 흐름도를 도시한다. 예를 들어, 프로세스(400)는 (예를 들어, Creturn 작업 흐름 서비스 모듈(387) 사용하는) 작업 흐름 서브-시스템(375)에 의해 전체적으로 또는 부분적으로 수행될 수 있다. 대체적으로 또는 추가적으로, 프로세스(400)의 일부 스텝은 최종 디바이스(107A-C, 119A-C) 또는 도 1a에 도시된 시스템과 관련된 임의의 다른 디바이스에 의해 수행될 수 있다. 다른 스텝은 외부 컴퓨터 디바이스(102a-b)와 같은 다른 디바이스에 의해 수행될 수 있다. 프로세스(400)가 작업 흐름 서브-시스템(375)과 관련하여 설명되나, 당업자는 도 4에 설명된 스텝이 예시적이고 일부 실시예에서 스텝이 추가, 병합, 분할, 복제, 반복, 수정 및/또는 삭제될 수 있음을 이해할 것이다.
스텝 405에서, 작업 흐름 서브-시스템(375)은 시스템(100)과 관련된 임의의 디바이스 상의 프로세스 중 하나에 대한 기존 작업 흐름을 표시할 수 있다. 프로세스는 연관된 작업 흐름이 있는 어떠한 프로세스도 될 수 있다. 예를 들어, 도 2에 도시된 풀필먼트 센터(200)는 주문 취소, 반환, 교환, 트래킹(tracking), 수집, 환불, 철회, 또는 주문 처리 및 풀필먼트와 관련된 임의의 다른 프로세스에 대한 작업 흐름과 관련된 프로세스를 가질 수 있다. 작업 흐름은 상호 연결된 복수의 인스트럭션(instruction) 블록(빌딩 블록(building blocks) 또는 단순히 블록이라고도 함)을 포함할 수 있다. 주문 취소와 관련된 작업 흐름은 전부 또는 일부 주문 취소 도 5, 사후 취소 도 6, 취소 승인 도 7, 취소 후 발송 중지 도 8에 대한 작업 흐름, 또는 주문 취소와 관련된 임의의 다른 작업 흐름을 포함할 수 있다. 주문 반환과 관련된 작업 흐름은 전부 또는 일부 주문 반환 도 9, 반환 후 처리 도 10, 반환 승인 도 11에 대한 작업 흐름, 또는 주문 반환과 관련된 임의의 다른 작업 흐름을 포함할 수 있다. 교환과 관련된 작업 흐름은 전부 또는 일부 주문 교환 도 12, 교환 후 처리 도 13, 미배송 교환 처리 도 14에 대한 작업 흐름, 또는 주문 교환과 관련된 임의의 다른 작업 흐름을 포함할 수 있다. 트래킹 및 수집과 관련된 작업 흐름은 부분 또는 전부 주문의 트래킹 및 수집 도 15a-b, 배달 트래킹 도 16, 수집 재시도 도 17, 수집 완료 도 18에 대한 작업 흐름, 또는 주문의 트래킹 또는 수집과 관련된 임의의 다른 작업 흐름을 포함할 수 있다. 환불과 연관된 작업 흐름은 부분 또는 전부 환불 도 19, 환불 완료 도 20에 대한 작업 흐름, 또는 환불 처리와 관련된 임의의 다른 작업 흐름을 포함할 수 있다. 철회와 관련된 작업 흐름은 취소 철회 도 21, 반환 철회 도 22, 교환 철회 도 23에 대한 작업 흐름, 또는 프로세스 철회에 대한 임의의 다른 작업 흐름을 포함할 수 있다. 본 개시와 관련된 작업 흐름은 어떤 맥락에서든 어떤 이유로든 작업 흐름이 사용되고 편집되어야 하는 모든 프로세스를 다루기 위한 것이다. 게다가, 이전 개시에 따른 각각의 작업 흐름은 복수의 상호 연결된 인스트럭션 블록을 포함할 수 있다. 인스트럭션 블록은 간단한 스텝을 구현하기 위한 사전 코딩된 인스트럭션을 포함할 수 있고 작업 흐름에 대한 빌딩 블록(building blocks)의 역할을 할 수 있다. 인스트럭션 블록은 상호 연결되어 작업 흐름을 형성한다, WorkflowStarter(381)에 의해 시작될 수 있는 명확한 시작과 작업 흐름을 종료하는 끝이 항상 있다.
스텝 410에서, 작업 흐름 서브-시스템(375)은 도 1에 도시된 시스템 중 하나의 사용자로부터 작업 흐름에 대한 편집을 수신할 수 있으며, 작업 흐름 편집이 개별 블록 및 그들의 상호 연결에 대한 편집을 포함한다. 표시된 작업 흐름의 다양한 블록을 조작하여 코드 없이 편집이 입력될 수 있다. 예를 들어, 일부 실시 예에서, 사용자는 마우스, 터치 스크린 또는 임의의 다른 적절한 사용자 인터페이스를 사용하여 블록을 드래그(drag) 및 드롭(drop)하여 블록을 조작할 수 있다. 최종 사용자는 어떤 이유로든 작업 흐름 블록 및 이들 간의 상호 연결을 추가, 제거 또는 수정할 수 있다. 예를 들어, 취소 작업 흐름 도 5의 맥락에서, 하나의 인스트럭션 블록은 취소가 물리적 제품에 대한 것인지 또는 디지털 제품에 대한 것인지를 결정하는데 사용될 수 있다. 물리적 상품의 취소는 디지털 상품의 무효화(nullification)와 다르므로 물리적 상품 및 디지털 상품을 모두 판매하는 최종 사용자는 이 특정 블록을 사용하여 취소 처리 작업 흐름을 개선할 수 있다. 한 가지 유형의 상품만을 판매하는 최종 사용자는 취소를 처리하기 전에 상품 유형을 결정할 필요가 없으므로 더 적은 스텝을 포함하는 더 간단하고 더 빠른 작업 흐름을 사용하도록 선택할 수 있다. 마찬가지로, 최종 사용자는 다른 부서들의 요구를 충족시키기 위해 상호 연결을 변경할 수 있다. 예를 들어, 취소 작업 흐름 도 5의 맥락에서, 일부 사용자는 취소 요청을 완료하기 전에 통계를 기록하도록 선택할 수 있는 반면 다른 사용자는 먼저 취소 요청을 완료한 다음 통계를 기록할 수 있다. 일 양상에서, 공연장에 콘서트를 전면 취소해야 한다는 점을 경고할 수 있기 때문에 티켓 판매 통계는 더 중요한 반면, 물리적 상품 판매에서, 제 시간에 적발될 경우 물리적 아이템이 풀필먼트 시설을 떠나기 전에 중단될 수 있으므로 취소 요청은 더 중요하다.
스텝 415에서, 작업 흐름 서브-시스템(375)은 수신된 편집에 기초하여 수정된 작업 흐름을 생성할 수 있다. 이 스텝에서, 도 3d에 관련한 이전의 개시에 따라 코드 없는 인터페이스를 통해 사용자에 의해 이루어진 어떠한 변경도 일관성을 위해 검증될 수 있고 시스템 사용을 위해 변환될 수 있다. 작업 흐름 서브-시스템(375)은 오류가 발견되면 사용자를 유도할 수 있다; 일부 실시예에서, 오류는 루프 논리(looped logic), 끝없는 작업 흐름, 또는 기타 부적절한 블록의 수정 또는 상호 연결의 형태일 수 있다. 변형된 편집은 수정된 작업 흐름으로 나타내어질 수 있다.
스텝 420에서, 작업 흐름 서브-시스템(375)은 수정된 작업 흐름을 시스템 전체에 전파할 수 있고, 원하는 경우 전파는 특정 부서로 제한될 수 있다. 일부 실시예에서, 작업 흐름 모델러(393)는 작업 흐름에 대한 변화를 다룰 수 있다; 사용자는 작업 흐름 모델러(393)에 의해 할당된 권한에 기초하여 최신 작업 흐름을 활용할 수 있다. 권한은 읽기, 쓰기, 실행, 또는 이들의 조합을 포함할 수 있다. 전파는 특정 부서와의 작업 흐름들을 함께 링크(link)함으로써 작업 흐름 서브-시스템(375)에 의해 수행되므로, 각 사용자가 변경을 수행하더라도 부서의 모든 사용자는 최신 사본을 가질 수 있다.
스텝 425에서, 작업 흐름 서브-시스템(375)은 추가 편집을 위해 수정된 작업 흐름을 표시할 수 있다. 수정된 작업 흐름은 도 1a에 도시된 시스템과 관련된 디바이스(107A-C, 119A-C) 또는 임의의 다른 디바이스의 GUI에 표시될 수 있다.
도 5-23과 관련하여 본 개시에서 추가로 논의되는 바와 같이, 블록은 사용자가 도 1 및 3a-d에 도시된 시스템에 의해 실행되는 작업 흐름을 구축하기 위해 미리 기록된 인스트럭션의 모음을 의미한다. 블록 간의 상호 연결은 마우스, 터치 스크린, 또는 기타 적절한 사용자 인터페이스를 사용하여 블록을 드래그(drag) 및 드롭(drop)함으로써 편집될 수 있다. 또한 각 블록 내에 포함된 인스트럭션은, 예를 들어 다른 소스로부터의 입력을 사용하여, 다양한 시나리오에 적용되도록 수정될 수 있다. 도 5-23에 도시된 작업 흐름은 예시로서 제공되며 상호 연결은 특정 사용 사례에 맞게 최종 사용자에 의해 이동되거나 수정될 수 있다. 수정된 작업 흐름은 마우스, 터치 스크린, 또는 기타 적절한 사용자 인터페이스를 사용하여 블록을 드래그(drag) 및 드롭(drop)함으로써 추가로 편집될 수 있다.
도 5는 취소 작업 흐름(500)을 포함하는 블록의 예시적인 배열을 나타낸다. 취소 작업 흐름(500)은 복수의 빌딩 블록들(510-545)을 포함할 수 있다. 추가 블록이 작업 흐름에 추가되거나, 기존 블록이 제거되거나, 사용자에 의해 블록의 위치가 변경될 수 있다. 예시적인 배열에서 취소 작업 흐름(500)은 결제가 진행되기 전에 주문이 취소되었는지 여부를 결정하는 것(505)으로 시작한다. 이전 개시에 따라 결정은 제어 서브-시스템(350)으로부터 결정을 획득하는 규칙 엔진(362)과 통신함으로써 작업 흐름 서브-시스템(375)에 의해 수행될 수 있다.
작업 흐름 서브-시스템(375)이 결제가 이루어지지 않았다고 결정하면, 취소 작업 흐름(500)은 결제 블록(510) 전에 취소 등록을 진행할 수 있다. 결제 블록(510) 전에 취소를 등록하는 것은 그 자체 내에 인스트럭션 블록을 포함할 수 있다. 블록(510) 내의 인스트럭션은 취소와 관련된 정보를 수집하고, 취소를 승인하고, 사용자에게 알림을 보내는 것을 포함할 수 있다. 알림은 이메일, 문자 메시지, 또는 기타 선호하는 방법과 같은 적절한 통신 방법을 통해 전송될 수 있다. 이전 개시에 따라 결제 블록(510) 전에 취소를 등록하는 것은 사용자에 의해 자체적으로 수정될 수 있다.
작업 흐름 서브-시스템(375)이 결제가 이루어졌다고 결정하면 취소 작업 흐름(500)은 프로모션(promotion)이 주문에 적용되는지 여부를 결정하는 것(515)으로 진행할 수 있다. 도 3a-d에 도시된 바와 같이 결정은 작업 흐름 서브-시스템(375)에 의해 이루어질 수 있고 다른 시스템과의 통신에 의존할 수 있다. 여기에 사용된 프로모션은 소비자에게 발송된 추가 아이템(예를 들어, 하나 구매시 하나 무료, 무료 샘플, 무료 서비스), 할인, 리베이트(rebate), 또는 취소 중인 아이템의 구매와 함께 제공되는 기타 혜택을 의미할 수 있다. 작업 흐름 서브-시스템(375)은 도 3a-d에 도시된 바와 같이 다른 시스템과 통신함으로써 프로모션이 주문 블록(515)에 적용되는지 여부를 결정할 수 있고 취소된 아이템과 함께 번들(bundle)된 아이템을 취소하기 위한 추가적인 작업 흐름 또는 프로모션 제품을 적절하게 처리하기 위해 필요한 기타 다른 인스트럭션을 시작할 수 있다. 이전 개시에 따라 블록(515)은 사용자에 의해 자체적으로 수정될 수 있다.
작업 흐름 서브-시스템(375)이 프로모션이 주문에 적용되는지 여부를 결정(515)한 후, 취소 작업 흐름(500)은 취소 요청 블록에 대한 데이터 생성(520)을 진행할 수 있다. 블록(520)은 추가 처리를 위해 사용되는 취소와 관련된 모든 데이터를 포함하는 리포트(report)를 생성할 수 있다. 도 3a-d에 도시된 바와 같이 생성은 작업 흐름 서브-시스템(375)에 의해 수행될 수 있고 다른 시스템과의 통신에 의존할 수 있다. 생성된 데이터는 취소 요청 유형을 결정하기 위해 블록(525)으로 전달될 수 있다.
블록(525)은 작업 흐름 서브-시스템(375)에 의해 취소가 제품 취소인지 또는 티켓 취소인지 여부를 결정하는 것에 관한 것이다. 여기서 사용된 티켓은 이벤트에 대한 입장권을 의미한다. 도 3a-d에 도시된 바와 같이 결정은 블록(520)에서 생성된 데이터에 의존할 수 있고 작업 흐름 서브-시스템(375)에 의해 수행될 수 있고 다른 시스템과의 통신에 의존할 수 있다. 작업 흐름 서브-시스템(375)이 취소가 티켓 취소라고 결정하는 경우 작업 흐름(500)은 블록(535)으로 진행하여 티켓 취소를 등록할 수 있다. 대체적으로, 제품 취소를 등록하기 위해 블록(530)으로 진행한다. 등록 블록들(530, 535)은 취소가 소비자의 잘못인지 여부를 결정하고, 무료 반환 배송이 제공되는지 여부를 결정하는 추가적인 인스트럭션을 포함할 수 있다((주문 금액)-(예상 환불 금액)<(무료 배송 비용)이면, 무료 배송 거부). 이전 개시에 따라 블록들(530, 535)은 사용자가 필요하다고 간주하는 임의의 추가적인 인스트럭션을 포함하도록 사용자에 의해 수정될 수 있다.
취소 등록이 완료된 후, 취소 작업 흐름(500)은 교차점(540)으로 진행할 수 있다. 교차점(540)은 사용자가 블록 간의 상호 연결을 수정하는 방법에 대한 예시이다. 사용자가 취소 요청 유형에 관계없이 블록(545)으로 진행하기로 결정한 도시된 예시에서, 다른 사용자가 이 단계에서 작업 흐름을 두 개로 분할하고 작업 흐름을 분할하는 것을 계속하도록 선택했을 수 있다는 점에 유의하는 것이 중요하다. 교차점(540)과 같은 교차점은 사용자가 개별 블록을 포함하는 모든 단일 인스트럭션에 내포된 메커니즘 또는 코드를 이해할 필요없이 다양한 블록의 상호 연결을 쉽게 수정할 수 있도록 한다.
교차점(540) 이후 취소 작업 흐름(500)은 취소 요청을 완료하기 위해 블록(545)으로 진행할 수 있다. 여기에 사용된 취소 요청 완료는 작업 흐름의 최종 태스크를 의미할 수 있다. 최종 태스크는 요청을 보고, 저장, 확인하는 것을 포함할 수 있다. 추가적으로, 그것은 결제 시스템으로 이전하기 위해 예상 환불 금액의 스냅 샷을 저장하는 것을 포함할 수 있다.
도 6은 개시된 실시예에 따른, 취소 후 작업 흐름(600)을 포함하는 블록의 예시적인 배열을 나타낸다. 도 3a-d에 도시된 바와 같이, 취소 후 작업 흐름(600)은 작업 흐름 서브-시스템(375)에 의해 수행될 수 있고 다른 시스템과의 통신에 의존 할 수 있다. 취소 후 작업 흐름(600)은 취소 후 프로세스를 설정하기 위해 블록(605)에서 시작할 수 있다. 취소 후 프로세스 설정은 취소 요청 조회, 요청 자동 승인 여부 결정, 주문 풀필먼트 중지 여부 결정, 관련 패키지 배송 방지에 사용될 수 있는 추가적인 인스트럭션 블록을 포함할 수 있다.
취소 후 작업 흐름(600)은 취소가 제품 취소인지 또는 티켓 취소인지를 결정하기 위한 블록(610)으로 진행할 수 있으며, 이는 일부 실시예에서 도 5에 도시된 취소 작업 흐름과 관련하여 사용되고 설명된 것과 동일한 블록인 블록(525)이다.
작업 흐름 서브-시스템(375)이 취소가 제품 취소라고 결정하는 경우, 작업 흐름(600)은 주문 풀필먼트가 중지되어야 하는지 여부를 결정하기 위해 블록(615)으로 진행할 수 있다. 이것은 도 1 및 3a-d에 도시된 바와 같이 시스템의 다른 부분과 통신함으로써 결정될 수 있다.
작업 흐름 서브-시스템(375)이 주문 풀필먼트가 실제로 중지되어야 한다고 결정하면, 작업 흐름(600)은 블록(620)으로 진행하여 주문 풀필먼트를 중지하고 관련된 패키지가 풀필먼트 센터를 떠나는 것을 중지하려고 시도할 수 있다. 블록(620)은 제품 취소 정보 등록, 제품의 현재 풀필먼트 상태 결정, 반환 작업 흐름 시작 및 제품에 대한 환불 처리에 대한 추가적인 인스트럭션을 포함할 수 있다. 추가적으로, 풀필먼트에 대한 중지 주문을 생성하고 제품이 있는 패키지가 떠나는 것을 중지하는 인스트럭션이 포함될 수 있다. 이러한 인스트럭션은 작업 흐름(600)을 사용자 정의할 때 최종 사용자에 의해 추가되거나 제거될 수 있다. 작업 흐름(600)의 다음 블록(625)은 주문 풀필먼트가 성공적으로 중지되었는지 결정하기 위해 사용될 수 있다. 주문이 중지되지 않았거나 중지할 수 없는 경우 작업 흐름(600)이 종료되고 주문 취소가 승인되지 않는다.
작업 흐름 서브-시스템(375)이 취소가 티켓 취소라고 결정하면, 작업 흐름(600)은 티켓 취소가 자동으로 승인될 수 있는지 여부를 결정하기 위해 블록(635)으로 진행할 수 있다. 블록(635)은 이러한 결정을 내리기 위해 도 1 및 3a-d에 설명된 제3 자(예를 들어, 예약 장소)와의 통신에 의존할 수 있다.
블록(635)에서 작업 흐름 서브-시스템(375)이 티켓 취소가 자동으로 승인된다고 결정하거나, 블록(615)에서 주문 풀필먼트 프로세스를 중지할 필요가 없다고 결정하거나, 블록(625)에서 주문 풀필먼트가 성공적으로 중지되었다고 결정하면, 작업 흐름(600)은 취소를 승인하기 위해 블록(630)으로 진행할 수 있다. 취소 승인 블록(630)은 보고, 저장, 취소 데이터 확인, 환불 금액 추정, 또는 임의의 다른 승인 관련 인스트럭션을 포함할 수 있다. 예시적인 작업 흐름(도 5-23) 내의 다른 모든 블록과 마찬가지로 그것은 특정 부서의 필요에 따라 사용자에 의해 수정될 수 있다.
블록(635)에서 작업 흐름 서브-시스템(375)이 티켓 취소가 자동으로 승인되지 않는다고 결정하면, 작업 흐름(600)은 예약 취소를 시작하기 위해 작업 흐름(640)을 시작할 수 있다. 예를 들어, 최종 사용자가 티켓을 판매만 하는 경우 예약 취소 작업 흐름(640)은 독립형 작업 흐름으로 사용될 수 있다. 도 3a-d에 도시된 바와 같이 예약 취소 작업 흐름(640)은 작업 흐름 서브-시스템(375)에 의해 수행될 수 있고 다른 시스템과의 통신에 의존할 수 있다.
예약 취소 작업 흐름(640)은 예약 장소에 연락하는 블록(645)에서 시작될 수 있다. 도 3a-d에 도시된 바와 같이 예약 장소는 외부 서비스 작업부(333)를 이용함으로써 연락될 수 있다. 예약 장소와 통신이 확립된 후 예약 취소 작업 흐름(640)은 티켓 취소 블록(650)을 시작하는 것으로 진행할 수 있다. 작업 흐름 서브-시스템(375)은 블록(650)에서 티켓 취소를 시작할 수 있고 취소 세부 사항과 함께 필요한 티켓 정보를 예약 장소에 전송할 수 있다. 블록(650) 이후, 작업 흐름(640)은 티켓 취소를 확인하는 블록(655)을 계속할 수 있다. 외부 서비스 작업부(333)는 예약 장소로부터 확인을 수신할 수 있다. 도 3a-d에 도시된 바와 같이 외부 서비스 작업부(333)는 작업 흐름 서브-시스템(375)에 확인을 전달할 수 있다. 마지막으로, 작업 흐름 서브-시스템(375)은 판매된 티켓을 무효화할 수 있다. 취소가 확인된 후 작업 흐름 서브-시스템(375)은 소비자에게 알릴 수 있고(660), 티켓 재고는 업데이트될 수 있다(665). 예약 취소 작업 흐름(640)은 최종 사용자에 의해 다양한 작업 흐름 내에서 수정되거나 구현될 수 있는 이벤트 티켓 무효화, 이벤트 장소 알림, 이벤트 티켓 취소 등록, 및 이벤트 취소에 대한 영수증 생성을 위한 추가적인 인스트럭션을 포함할 수 있다.
도 7은 취소 승인 작업 흐름(700)을 포함하는 블록의 예시적인 배열을 나타낸다. 도 3a-d에 도시된 바와 같이 작업 흐름(700)은 작업 흐름 서브-시스템(375)에 의해 수행될 수 있고 다른 시스템과의 통신에 의존할 수 있다. 작업 흐름(700)은 취소 요청 승인 블록(705)에서 시작할 수 있다. 취소 요청 승인 블록은 데이터 확인, 고객 유효성 검사 등과 같은 환불 처리 전에 취소 요청에 대한 마감 절차를 실행할 수 있다. 취소 요청이 승인된 후(705), 작업 흐름(700)은 주문을 취소하는 블록(710)의 시도를 계속할 수 있다. 주문 취소는 주문 상태를 "P"에서 "H"로 변경하여 (일부 실시예에서, 주문 상태는 "결제(payment)"에 대해 P, "진행중인 취소(cancellation in progress)"에 대해 H, 및 “취소됨(cancelled)”에 대해 C 중 하나를 포함함) 주문이 취소 중이며 다른 작업 흐름에서 처리되어서는 안됨을 나타낼 수 있다. 도 21-23을 참조하여 후술되는 바와 같이 주문 상태 변경은 또한 철회 작업 흐름을 시작할 수 있다.
다음 블록(715)은 주문이 적절하게 취소되었는지 결정하기 위해 사용될 수 있다. 여기에 사용된 주문을 적절하게 취소하는 것은 주문이 오류없이 완전히 취소되었음을 나타낼 수 있다. 도 1 및 3a-d에 도시된 바와 같이 결정은 작업 흐름 서브-시스템(375)에 의해 이루어질 수 있고 다른 시스템과의 통신에 의존할 수 있다. 작업 흐름 서브-시스템(375)이 주문 취소에 실패했다고 결정하면(720) 환불이 여전히 처리될 수 있다. 취소 실패(720) 이후, 현재 작업 흐름(700)은 종료될 수 있고 발견된 오류를 수정하기 위해 추가 작업 흐름이 시작될 수 있다. 대체적으로, 작업 흐름 서브-시스템(375)이 주문이 적절하게 취소되었다고 결정하면 작업 흐름(700)은 이것이 자동 취소였는지 여부를 결정하기 위해 블록(725)을 계속할 수 있다. 블록(725)은 도 6 및 작업 흐름(600)을 참조하여 설명된 블록(635)과 유사하다. 취소가 자동이면 작업 흐름(700)은 추가 동작이 필요하지 않기 때문에 종료된다. 대체적으로, 작업 흐름(700)을 종료하기 전에 취소가 자동이 아닌 경우 최종 취소 승인이 발행된다(730).
도 8은 개시된 실시예에 따라, 취소 후 발송-중지(stop-release) 작업 흐름을 포함하는 블록의 예시적인 배열을 도시한다. 도 3a-d에 도시된 바와 같이 작업 흐름(800)은 작업 흐름 서브-시스템(375)에 의해 수행될 수 있고 다른 시스템과의 통신에 의존할 수 있다. 작업 흐름(800)은 주문 풀필먼트를 중지하기 위한 데이터를 검색함으로써 블록(805)에서 시작할 수 있다. 이러한 데이터는 항목 별 주문 세부 정보, 주문 풀필먼트 센터 정보, 유통 경로 등을 포함할 수 있다. 작업 흐름(800)은 블록(810)으로 계속하여 주문 풀필먼트를 중지하려는 이전 시도가 있었는지 여부를 결정할 수 있다. 작업 흐름 서브-시스템(375)이 이것이 첫 번째 시도라고 결정하는 경우 작업 흐름(800)은 주문 풀필먼트를 중지(825)하려고 시도할 수 있다. 블록(830)에서 작업 흐름 서브-시스템(375)이 주문 풀필먼트가 성공적으로 중지되었다고 결정하면 작업 흐름(800)이 종료될 수 있다. 대체적으로, 주문 작업 흐름(800)이 풀필먼트 중지에 실패하면(835) 실패의 기록은 작업 흐름(800)을 종료하기 전에 저장될 수 있다. 기록을 유지하는 것은 작업 흐름(800)이 주문 풀필먼트를 중지하려는 후속 시도에서 다른 경로를 취하도록 할 수 있다.
작업 흐름 서브-시스템(375)이 이전에 실패한 풀필먼트 중지 시도의 기록이 있다고 결정하면 블록(810)은 주문 풀필먼트의 상태가 재평가되어야 한다고 결정(815)한다. 블록(815)은 주문 풀필먼트의 상태가 지난 시도 이후에 변경되었는지 평가할 수 있다(예를 들어, 첫 번째 창고를 떠나 현재 두 번째 창고로 가는 중임). 대체적으로 블록(820)은 주문이 이미 이행(fulfill)되었다고 결정할 수 있다. 이 경우에 블록(840)에서 회수 요청이 생성될 수 있고 작업 흐름(800)은 종료된다. 회수 요청의 생성은 도 15-18을 참조하여 더 상세히 설명되는 회수 작업 흐름을 시작할 수 있다.
그러나, 블록(820)이 주문이 아직 이행되지 않았다고 결정하면 작업 흐름(800)은 풀필먼트를 중지하려는 두 번째 시도를 위해 블록(825)으로 되돌아갈 수 있다. 작업 흐름(800)은 주문이 이행되거나 풀필먼트가 중지될 때까지 여러 번 시작될 수 있다. 작업 흐름(800)이 시작되는 시간은 주문에서 아이템의 수 및 각 아이템이 배달되기 전에 방문하는 허브의 수에 따라 달라질 수 있다.
도 9는 개시된 실시 예에 따른, 반환 작업 흐름(900)을 포함하는 블록의 예시적인 배열을 나타낸다. 도 3a-d에 도시된 바와 같이 작업 흐름(900)은 작업 흐름 서브-시스템(375)에 의해 수행될 수 있고 다른 시스템과의 통신에 의존할 수 있다. 작업 흐름(900)은 프로모션 제품을 확인함으로써 블록(905)에서 시작할 수 있다. 블록(905)은 작업 흐름(500) 및 도 5를 참조하여 앞서 설명된 블록(515)과 유사하게 구현될 수 있다. 작업 흐름(900)은 반환을 승인하기 위한 데이터를 검색하기 위해 블록(910)으로 계속할 수 있다. 반환을 승인하기 위한 데이터는 각 공급 업체에 대한 반환 가능 아이템과 관련된 ID 목록을 포함하고, 제품 유형에 기초하여 로지스틱 구성을 지정하고, 풀필먼트 상태 및 배달 패키지에 대한 ID를 설정할 수 있다. 예를 들어, 외부 서비스 프록시(331)는 주문 데이터 "LogisticsType", 아이템 데이터 "VendorItem (IDs)", 시스템(101)으로부터의 배달 데이터, 또는 주문과 관련된 임의의 다른 데이터를 제공할 수 있다. 작업 흐름(900)은 반환된 아이템이 3PL 제품인 곳을 결정하는 블록(915)으로 이어질 수 있다. 3PL 제품은 도 1을 참조하여 앞서 설명된 바와 같은 제3 자 풀필먼트(3PL) 시스템(121A-121C)에 의해 처리될 수 있다. 블록(920)은 3PL 제품을 다른 제품과 분리하기 위해 구현될 수 있다. 블록(925)은 반환 요청을 등록하기 위해 이어질 수 있습니다. 블록 925는 반환 요청 데이터의 유효성을 확인할 수 있으며, 유효하지 않은 데이터가 있으면, 도 3을 참조하여 설명한 이전 개시에 따라 BPM 엔진(391)에 의해 오류로 캡쳐되고 처리될 수 있는 반환 요청 제출 실패 예외가 발생할 수 있다.
제품 반환 요청이 작업 흐름 서브-시스템(375)에 의해 등록된 후, 작업 흐름 서브-시스템(375)은 소비자 유형(예를 들어, 정규 회원, 프리미엄 회원, VIP 회원 등)을 결정(940)하기 위해 보충 작업 흐름(930)을 시작할 수 있고, 무료 반환에 대한 적격성을 검증(945)할 수 있고(예를 들어, 적격성은 소비자 유형, 주문 가격 등에 기반할 수 있음), 미반환 환불에 대한 적격성을 확인(950)할 수 있다. 도 3a-d에 도시된 바와 같이 블록(940-950)은 작업 흐름 서브-시스템(375)이 외부 데이터 소스(370)로부터 데이터를 검색함으로써 수행될 수 있다. 여기에 사용된 미반환 환불은 반환이 필요하지 않은 환불을 의미한다(예를 들어, 디지털 또는 소멸된 상품). 작업 흐름(900)은 반환 요청의 등록을 완료하여 블록(960)으로 종료된다. 반환 요청을 완료하는 것은 작업 흐름의 최종 태스크를 의미할 수 있다. 도 3a-d에 도시 된 바와 같이 작업 흐름 서브-시스템(375)에 의해 수행되는 최종 태스크는 요청을 보고, 저장, 확인하는 것을 포함할 수 있다.
도 10은 개시된 실시 예들에 따른, 반환 후 프로세스 작업 흐름(1000)을 포함하는 블록의 예시적인 배열을 나타낸다. 도 3a-d에 도시된 바와 같이 작업 흐름(1000)은 작업 흐름 서브-시스템(375)에 의해 수행될 수 있고 다른 시스템과의 통신에 의존할 수 있다. 작업 흐름(1000)은 작업 흐름 서브-시스템(375)이 반환 후 프로세스를 설정하는 블록(1005)에서 시작할 수 있다. 여기에 사용된 반품 후는 초기 반환 작업 흐름이 완료된 후 발생하는 프로세스를 의미한다(예를 들어, 초기 데이터 수집 후). 여기에 사용된 프로세스 설정은 요청에 대한 설정 구성(예를 들어, 풀필먼트 중지 여부 설정, 자동 승인 여부 설정, 판매자에 의해 취소가 시작되었는지 여부 설정 등)을 의미할 수 있다. 프로세스 유형에 기초하여 설정은 사전 설정될 수 있으며 그에 따라 작업 흐름은 단지 요청 설정을 업데이트(설정) 한다. 사전 설정은 외부 데이터 소스(370)에 저장될 수 있고, 작업 흐름 서브-시스템(375)은 사전 설정에 따라 요청 설정을 설정하기 위해 그에 액세스 할 수 있다.
반품 후 프로세스가 설정된 후, 작업 흐름 서브-시스템(375)은 풀필먼트를 중지할 수 있는지 여부를 결정할 수 있다(1015). Yes이면, 프로세스는 블록(1020)으로 계속되어, 풀필먼트가 성공적으로 중지되고, 작업 흐름 서브-시스템(375)은 반환을 승인(1050)할 수 있고 작업 흐름(1000)을 종료하거나 반환 알림 작업 흐름(1055)을 시작할 수 있다. No이거나 풀필먼트가 중지될 수 없으면, 작업 흐름 서브-시스템(375)은 회수를 요청할 수 있는 블록(1010)으로 진행한다. 다음으로 프로세스는 블록(1025)로 진행하고, 여기서 작업 흐름 서브-시스템(375)은 회수 요청을 SAT 시스템(101)에 제출하려고 시도한다. 회수 요청이 실패하면(1035) 작업 흐름(1000)은 종료되거나 다시 시작될 수 있다. 회수 요청이 성공하면(블록(1025)의 "Yes"), 작업 흐름 서브-시스템(375)은 회수 요청이 자동 승인에 적합한지 여부를 결정하는 블록(1045)으로 진행할 수 있다. 작업 흐름 서브-시스템(375)은, 예를 들어, 외부 데이터 소스(370)로부터 추가 정보를 검색함으로써, 주문된 아이템 또는 주문과 관련된 소비자에 기초하여 결정을 할 수 있다. 작업 흐름 서브-시스템(375)이 회수가 자동 승인에 적합하다고 결정하면 반환은 블록(1050)에서 승인되고 작업 흐름(1000)은 종료되거나 보충 반환 알림 작업 흐름(1055)이 시작될 수 있다.
보충 반환 알림 작업 흐름(1055)은 블록(1050) 이후 또는 아이템이 자동 승인에 적합하지 않은 경우 블록(1045) 이후에 작업 흐름 서브-시스템(375)에 의해 실행될 수 있다. 작업 흐름(1055)은 블록(1060)에서 시작하며, 여기서 작업 흐름 서브-시스템(375)은 반환 요청 수신의 도 3a-d에 도시된 다른 시스템에 알린다. 또한, 작업 흐름 서브-시스템(375)은 블록(1065)에서 회수의 알림을 제공하고 상태 업데이트와 함께 소비자 메시지를 전송할 수 있다. 작업 흐름(1055)이 완료되기 전에, 도 10에 예로서 도시된 바와 같이, 작업 흐름 서브-시스템(375)은 또한 블록(1075)에서 교체품이 품절되면 소비자에게 알린다.
도 11은 개시된 실시 예에 따른, 반환 승인 작업 흐름(1100)을 포함하는 예시적인 블록의 배열을 나타낸다. 도 3a-d에 도시된 바와 같이 작업 흐름(1100)은 작업 흐름 서브-시스템(375)에 의해 수행될 수 있고 다른 시스템과의 통신에 의존할 수 있다. 작업 흐름(1100)은 풀필먼트가 성공적으로 중지되었다고 가정하고 블록(1105)에서 시작한다. 블록(1105)에서, 작업 흐름 서브-시스템(375)은 반환을 승인할 수 있다. 블록(1105)은 도 10에 도시된 작업 흐름(1000)의 블록(1050)과 유사하고 이전 개시에 따른다. 작업 흐름 서브-시스템(375)이 블록(1100)에서 반환을 승인하면 주문을 취소(1110)하는 것으로 진행될 수 있으며, 이는 작업 흐름(700)의 블록(710)과 유사하며 이전 개시에 따른다. 작업 흐름 서브-시스템(375)은 이전 개시에 따라 블록(1115)에서 주문이 적절하게 취소되었는지 여부를 결정하고 만약 그렇다면 작업 흐름(1100)을 종료할 것이다. 그렇지 않으면, 작업 흐름(1100)을 종료하기 전에, 작업 흐름 서브-시스템(375)은 추가적인 작업 흐름을 시작하는 블록(1120)에서 반환 상태를 "환불 처리 중"으로 업데이트할 것이다.
도 12는 개시된 실시예에 따른, 교환 작업 흐름(1200)을 포함하는 블록의 예시적인 배열을 나타낸다. 도 3a-d에 도시된 바와 같이 작업 흐름(1200)은 작업 흐름 서브-시스템(375)에 의해 수행될 수 있고 다른 시스템과의 통신에 의존할 수 있다. 작업 흐름(1200)은 블록(1205)에서 교환 요청과 관련된 데이터를 검색하는 작업 흐름 서브-시스템(375)에 의해 시작된다. 데이터는 외부 데이터 소스(370)로부터 검색될 수 있고, 교환 프로세스와 관련된 임의의 데이터(예를 들어, 원래 주문 시간, 원래 가격, 결제 방법, 소비자 주소 등)를 포함할 수 있다. 외부 데이터 소스(370)로부터 데이터를 이용할 수 없는 경우, 도 3a-d에 도시된 바와 같이 작업 흐름 서브-시스템(375)은 다른 시스템으로부터 데이터를 검색할 수 있다. 작업 흐름 서브-시스템(375)은 도 3a-d에 도시된 바와 같이 모든 상호 연결된 시스템에 걸쳐 블록(1210)에서 교환 요청을 등록하는 것으로 진행한다.
작업 흐름(1200)은 결함이 있는 아이템이 반환되어야 하는지 여부를 결정하는 작업 흐름 서브-시스템(375)으로 계속된다. 작업 흐름 서브-시스템(375)은, 예를 들어, 반환 서비스(329c)와 통신함으로써, 블록(1215)에서 반환이 필요한지 여부를 결정한다. 작업 흐름 서브-시스템(375)이 반환이 필요하지 않다고 결정하면 블록(1220)에서 미반환 환불을 적용할 수 있다. 그렇지 않으면 블록(1225)에서 교환 요청은 완료되고 추가 처리를 위해 추가적인 작업 흐름이 호출될 수 있다.
도 13은 개시된 실시예에 따른, 교환 후 작업 흐름(1300)을 포함하는 블록의 예시적인 배열을 나타낸다. 도 3a-d에 도시된 바와 같이 작업 흐름(1300)은 작업 흐름 서브-시스템(375)에 의해 수행될 수 있고 다른 시스템과의 통신에 의존할 수 있다. 작업 흐름(1300)은 블록(1305)에서 시작한다. 블록(1305)에서 작업 흐름 서브-시스템(375)은 이전 개시에 따른 교환 후 프로세스를 설정한다. 그 다음 작업 흐름 서브-시스템(375)은 블록(1310)에서 교환이 직접적인지 여부를 결정한다. 여기서 사용되는 직접 교환은 제3 자 또는 해외 리셀러(reseller)와 접촉하지 않고 시스템에 의해 수행되는 교환을 의미할 수 있다. 블록(1310)에서의 결정은 도 3a-d에 도시된 다른 시스템과 통신함으로써 이루어진다. 예를 들어, 작업 흐름 서브-시스템(375)은 아이템의 판매자에 관한 정보 및 교환이 처리되어야 하는 방법을 검색하기 위해 외부 데이터 소스(370)와 통신할 수 있다. 교환이 직접적이지 않은 경우 작업 흐름 서브-시스템(375)은 도 3a-d에 도시된 바와 같이 추가 시스템에 접촉함으로써 블록(1315)에서 교환 회수 요청을 시작하고 블록(1320)에서 아이템이 해외로부터 왔는지 결정할 것이다. 아이템이 해외로부터 온 것으로 결정되면 작업 흐름 서브-시스템(375)은, 예를 들어, 추가 처리를 위해 업데이트된 정보를 Creturn domains(327)에 전달함으로써, 블록(1325)에서 교환 회수 요청을 업데이트할 수 있다.
작업 흐름(1300)은 블록(1340)으로 진행할 수 있다. 블록(1340)에서 작업 흐름 서브-시스템(375)은 소매를 통해 교환 요청이 이루어 졌는지 여부를 결정할 수 있다. 블록(1340)은 다음과 같은 경우에 활성화된다: (1) 블록(1330)에서 직접 교환이 요청됨; (2) 블록(1320)에서 결정된 바와 같이 요청 교환이 해외로부터 회수되고 블록(1325)에서 회수 요청이 업데이트됨; 또는 (3) 블록(1320)에서 결정된 바와 같이 요청 교환이 해외로부터 회수되지 않음. 작업 흐름 서브-시스템(375)이 블록(1340)에서 교환 요청이 소매를 통해 이루어 졌다고 결정하면, 블록(1345)에서 풀필먼트가 중지된다. 작업 흐름 서브-시스템(375)은 외부 데이터 소스(370)와 통신함으로써 교환 요청이 직접적인지 아닌지 여부를 결정할 수 있다. 블록(1345)에서 풀필먼트를 중지하기 위해, 작업 흐름 서브-시스템(375)은 SAT 시스템(101)에 요청을 할 수 있다. 소비자가 일반적으로 소매점에서 교환 아이템을 픽업할 것이라는 사실 때문에 풀필먼트가 중지되어야 할 수 있고, 창고에 의한 풀필먼트는 필요하지 않을 것이다.
보충 알림 작업 흐름(1350)은 블록(1345) 이후에 또는 대체적으로 블록(1340)에서 작업 흐름 서브-시스템(375)에 의해 부정적 결정이 이루어진 경우 작동할 수 있다. 보충 작업 흐름(1350)은 블록(1355)에서 시작한다. 블록(1355)에서 작업 흐름 서브-시스템(375)은, 예를 들어 더 비싼 아이템이 교체품으로 주문되는 경우, 조정을 교환 요청에 링크(link)할 수 있다. 작업 흐름 서브-시스템(375)은 교환이 요청될 수 있는 시기에 시간 제한을 두어, 블록(1360)에서 교환 차단을 알릴 수 있다. 작업 흐름 서브-시스템(375)은 이메일 또는 문자 메시지를 전송함으로써 수행될 수 있는 교환의 상태를 소비자에게 알릴 수 있다 (1365). 그리고 블록(1370)에서 작업 흐름 서브-시스템(375)이 외부 데이터 소스(370)와 통신함으로써 소매점을 통해 요청이 이루어 졌다고 결정하면, 작업 흐름 서브-시스템(375)은 또한 블록(1375)에서 소매점에 알릴 수 있다.
도 14는 개시된 실시 예에 따른, 미배송 교환 작업 흐름(1400)을 포함하는 블록의 예시적인 배열을 나타낸다. 도 3a-d에 도시된 바와 같이 작업 흐름(1400)은 작업 흐름 서브-시스템(375)에 의해 수행될 수 있고 다른 시스템과의 통신에 의존할 수 있다. 작업 흐름(1400)은 블록(1405)에서 시작한다. 블록(1405)에서 작업 흐름 서브-시스템(375)은 도 3a-d에 도시된 바와 같이 다른 시스템(예를 들어, 외부 데이터 소스(370))으로부터의 교환을 위한 재시도 요청에 대한 교환 요청과 관련된 데이터를 검색한다. 작업 흐름 서브-시스템(375)이 블록(1410)에서 재시도가 필요하지 않다고 결정하는 경우, 즉 교환이 성공적이거나 취소되었음을 의미하는 경우, 작업 흐름 서브-시스템(375)은 블록(1430)에서 교환 아이템의 품절을 담당 시스템에 알릴 수 있다. 여기서 사용된 '품절'은 아이템이 풀필먼트 센터에서 원래 위치를 떠났고 재고에 다시 넣으려면 회수되어야 한다는 사실을 의미할 수 있다. 그렇지 않으면, 작업 흐름 서브-시스템(375)은 블록(1415)에서 교환 요청을 수락하고 블록(1420)에서 교환을 위한 재시도 후 요청을 설정할 것이다. 여기서 사용된 '재시도 후 교환'은 재시도가 이루어진 후 발생하는 프로세스를 의미한다. 여기에 사용된 프로세스 설정은 앞에서 설명한 바와 같이 요청에 대한 설정을 구성하는 것을 의미할 수 있다. 작업 흐름 서브-시스템(375)이 블록(1425)에서 재시도 후 모든 프로세스를 완료한 후, 작업 흐름 서브-시스템(375)은 블록(1430)에서 교환된 아이템이 품절되었음을 담당 시스템에 알릴 수 있다.
도 15a 및 15b는 개시된 실시예에 따른, 트래킹 수집 작업 흐름을 포함하는 블록의 예시적인 배열을 나타낸다. 도 3a-d에 도시된 바와 같이 작업 흐름(1500)은 작업 흐름 서브-시스템(375)에 의해 수행될 수 있고 다른 시스템과의 통신에 의존할 수 있다. 작업 흐름(1500)은 블록(1505)에서 시작한다. 블록(1505)에서 작업 흐름 서브-시스템(375)은 트래킹 정보 검색을 위한 소비 잠금을 설정할 수 있다. 작업 흐름 서브-시스템(375)은 소비 잠금을 예를 들어 외부 데이터 소스(370)의 기존 데이터와 비교함으로써 블록에서 중복 트래킹이라고 결정(1510)하는 경우, 작업 흐름(1500)은 종료된다. 그렇지 않으면, 작업 흐름은 블록(1520, 1525)로 계속될 수 있다. 블록(1520)에서 작업 흐름 서브-시스템(375)은 트래킹 정보를 기록할 수 있고 블록(1525)에서 작업 흐름 서브-시스템(375)은 트래킹이 교환 또는 반환 요청과 관련되는지 여부를 결정할 수 있다. 결정은 소비 잠금(consuming lock)에서 트래킹과 관련된 정보에 기초할 수 있으며, 정보는 외부 데이터 소스(370) 또는 다른 작업 흐름으로부터 수신될 수 있다. 회수가 반환 요청에 대한 것으로 결정되면, 이전 개시에 따라, 블록(1530)에서 작업 흐름 서브-시스템(375)은 반환 트래킹을 처리할 수 있고, 작업 흐름(1500)은 종료될 수 있다. 작업 흐름 서브-시스템(375)이 회수가 교환 요청에 대한 것이라고 결정하면 작업 흐름 서브-시스템(375)은 블록(1535)에서 외부 데이터 소스(370)로부터 추가 데이터를 검색할 수 있다. 또한, 작업 흐름 서브-시스템(375)은 도 3a-d에 도시된 바와 같이 SAT 시스템(101) 또는 다른 시스템과 통신함으로써 교환 회수를 수행할 수 있는지 여부를 결정한다(1540). 가능하다면 작업 흐름 서브-시스템(375)은 블록(1545)에서 교환 트래킹을 처리할 수 있다.
도 15b로 이동하여, 작업 흐름 서브-시스템(375)은 블록(1550)에서 교환에 대한 알림이 필요한지 여부를 결정한다. 이 결정을 하기 위해 작업 흐름 서브-시스템(375)은 외부 데이터 소스(370)로부터 필요한 정보를 검색한다. 또한, 작업 흐름 서브-시스템(375)은 블록(1565)에서 교환 회수/배달 상태 변경을 링크(link)할 수 있고 블록(1570)에서 교환 차단을 알릴 수 있다. 블록(1570) 또는 블록(1550)에서의 부정적 결정 다음으로, 작업 흐름 서브-시스템(375)은 배달 교환이 필요한지 결정하고(1575), 작업 흐름 서브-시스템(375)은 교환 배달 요청을 생성(1580) 할 수 있다. 도 1 및 3a-d에 도시된 바와 같이 작업 흐름 서브-시스템(375)에 의해 외부 데이터 소스(370) 또는 다른 시스템과 통신함으로써 필요성이 결정될 수 있다.
도 16은 개시된 실시예에 따른, 배달 트래킹 작업 흐름(1600)을 포함하는 블록의 예시적인 배열을 나타낸다. 도 3a-d에 도시된 바와 같이 작업 흐름(1600)은 작업 흐름 서브-시스템(375)에 의해 수행될 수 있고 다른 시스템과의 통신에 의존할 수 있다. 작업 흐름(1600)은 기본적으로 동일한 빌딩 블록을 사용하여 작업 흐름(1500)을 미러링한다. 작업 흐름(1600)에서, 블록(1605-1650)은 (각각) 도 15a 및 15b의 블록(1505-1550)과 실질적으로 동일하게 동작한다. 또한 보충 작업 흐름(1655)은 보충 작업 흐름(1560)과 실질적으로 동일하다. 작업 흐름(1600)과 작업 흐름(1500) 간의 주요 차이점은 (1) 블록(1610, 1625, 1630, 1645)에서 작업 흐름 서브-시스템(375)이 회수 트래킹이 아닌 배달 트래킹을 활용하고, 및 (2) 블록(1555, 1575, 1580)에서의 작업 흐름(1500)처럼 작업 흐름(1600)이 필요성을 확인할 필요가 없다는 것이다. 이것은 동일한 빌딩 블록이 상이한 목표를 달성하기 위해 상이한 시스템에 의해 사용될 수 있음을 보여준다.
도 17은 개시된 실시예에 따른, 수집 재시도 작업 흐름(1700)을 포함하는 블록의 예시적인 배열을 나타낸다. 도 3a-d에 도시된 바와 같이 작업 흐름(1700)은 작업 흐름 서브-시스템(375)에 의해 수행될 수 있고 다른 시스템과의 통신에 의존할 수 있다. 작업 흐름(1700)은 블록(1705)에서 시작한다. 블록(1705)에서, 작업 흐름 서브-시스템(375)은 회수 요청이 재시도임을 확인한다. 그렇지 않은 경우, 작업 흐름 서브-시스템(375)은 블록(1710)에서 요청을 업데이트하고 도 17에서 예시로 설명한 바와 같이 현재 작업 흐름을 종료하거나 대체적으로 적절한 작업 흐름(미도시)을 시작할 수 있다.
작업 흐름 서브-시스템(375)이 회수 요청이 재시도임을 확인하면, 작업 흐름 서브-시스템(375)은 블록(1715)에서 재시도 조건을 설정한다(예를 들어, 회수를 X 번 더 시도함). 블록(1720)에서, 작업 흐름 서브-시스템(375)은 SAT 시스템 (101)과 통신함으로써, 주문 회수가 성공했는지를 결정한다. 주문이 성공적으로 회수되면(블록(1720)의 "No") 작업 흐름이 종료된다. 그렇지 않으면, 작업 흐름 서브-시스템(375)은 블록(1725)에서 재시도 조건을 업데이트할 수 있다. (1) 블록(1730)에서 SAT 시스템(101)과 통신함으로써 작업 흐름 서브-시스템(375)에 의해 결정된 바와 같이 소비자 부재로 인해 주문이 회수되지 않았고 (2) 블록(1735)에서 작업 흐름 서브-시스템(375)이 외부 데이터 소스(370)와 통신함으로써 주문이 자동 반환 취소에 적격성이 인정된다고 간주하는 경우, 작업 흐름 서브-시스템(375)은 블록(1750)에서 자동 취소를 위한 데이터를 수집하고 블록(1755)에서 반환을 취소할 수 있다. 블록(1735)에서 외부 데이터 소스(370)와 통신함으로써 작업 흐름 서브-시스템(375)에 의해 주문이 자동 취소에 적격성이 인정되지 않는다고 결정되는 경우, 먼저 작업 흐름 서브-시스템(375)은 외부 데이터 소스(370)와 통신함으로써 블록(1740)에서 그것이 자동으로 취소되어야 하는지 여부를 확인할 수 있고 그렇다면 블록(1745)에서 회수를 취소할 수 있다. 다른 모든 경우에 작업 흐름(1700)은 종료되고 추가적인 작업 흐름이 작업 흐름 서브-시스템(375)에 의해 시작되고 및/또는 예외를 처리하기 위해 최종 사용자에 의해 구성되어야 할 수 있다.
도 18은 개시된 실시예에 따른, 수집 완료 작업 흐름(1800)을 포함하는 블록의 예시적인 배열을 나타낸다. 도 3a-d에 도시된 바와 같이 작업 흐름(1800)은 작업 흐름 서브-시스템(375)에 의해 수행될 수 있고 다른 시스템과의 통신에 의존할 수 있다. 작업 흐름(1800)은 블록(1805)에서 시작할 수 있다. 블록(1805)에서, 작업 흐름 서브-시스템(375)은 반환 전 환불에 대한 적격성을 검증한다. 작업 흐름 서브-시스템(375)은 외부 데이터 소스(370)와 통신하여, 예를 들어 아이템 설명을 검색하거나 고객 유형을 결정함으로써, 적격성을 검증할 수 있다. 작업 흐름 서브-시스템(375)이 블록(1810)에서 반환 전 환불이 필요하지 않다고 결정하면, 작업 흐름 서브-시스템(375)은 블록(1815)에서 반환 전 환불을 거절하고 작업 흐름(1800)을 종료한다. 작업 흐름 서브-시스템(375)이 블록(1810)에서 반환 전 환불이 필요하다고 결정하면, 작업 흐름 서브-시스템(375)은 블록(1820)에서 외부 데이터 소스(370)로부터 반환 승인과 관련된 정보를 검색하고 블록(1825)에서 도 1 및 3a-d에 도시된 시스템과 통신하여, 예를 들어 Creturn domains(327)에 정보를 전송함으로써, 반환을 승인한다.
도 19는 개시된 실시예에 따른 환불 요청 작업 흐름(1900)을 포함하는 예시적인 블록의 배열을 나타낸다. 도 3a-d에 도시 된 바와 같이 작업 흐름(1900)은 작업 흐름 서브-시스템(375)에 의해 수행될 수 있고 다른 시스템과의 통신에 의존할 수 있다. 작업 흐름(1900)은 블록(1905)에서 시작한다. 블록(1905)에서, 작업 흐름 서브-시스템(375)은 외부 데이터 소스(370)로부터 환불 요청과 관련된 정보를 검색할 수 있다. 블록(1910)에서 작업 흐름 서브-시스템(375)은 검색된 정보에 기초하여 주문이 환불에 적격성이 인정되는지 여부를 결정한다. 적격성이 인정되지 않으면 작업 흐름(1900)은 종료된다. 적격성이 인정되면, 작업 흐름 서브-시스템(375)은 블록(1915)에서 추가 정보를 검색할 수 있으며, 추가 정보는 예를 들어 결제 세부 사항을 포함할 수 있고 외부 데이터 소스(370)로부터 검색될 수 있다. 블록(1920)에서, 작업 흐름 서브-시스템(375)은 Creturn domains(327)과 통신함으로써 처리될 환불을 요청한다. 다음으로, 블록(1925)에서 작업 흐름 서브-시스템(375)은 규칙 엔진(362)과 통신함으로써 환불 취소가 차단되는지 여부를 결정할 수 있다. 환불 취소가 차단되지 않으면 작업 흐름(1900)이 종료된다. 대체적으로 그것이 차단되면, 블록(1930)에서 작업 흐름 서브-시스템(375)은 규칙 엔진(362)과 통신함으로써 환불 취소 요청을 차단 해제한다. 블록(1925)에서의 확인 및 블록(1930)에서의 차단 해제는 환불 요청이 철회되는 경우에 필수적이며 규칙 엔진(362)이 있는 환불 취소 블록을 확인하는 다른 작업 흐름에 의해 취소되어야 한다.
도 20은 개시된 실시예에 따른, 환불 완료 작업 흐름(2000)을 포함하는 블록의 예시적인 배열을 나타낸다. 도 3a-d에 도시된 바와 같이 작업 흐름(2000)은 작업 흐름 서브-시스템(375)에 의해 수행될 수 있고 다른 시스템과의 통신에 의존할 수 있다. 작업 흐름(2000)은 블록(2005)에서 시작할 수 있다. 블록(2005)에서, 작업 흐름 서브-시스템(375)은, 예를 들어 외부 데이터 소스 (370)로부터 상태 정보를 검색하거나 요청에 미해결 문제(블록 또는 다른 보류중인 작업 흐름과 같은)가 없음을 규칙 엔진(362)으로 확인함으로써, 도 3a-d에 도시된 바와 같이 다른 시스템으로 확인하여 상태를 "환불 완료"로 업데이트하기 위한 적격성을 확인한다. 확인이 통과되고 블록(2010)에서 작업 흐름 서브-시스템(375)이 상태를 "환불 완료"로 변경해야 한다고 결정하면, 블록(2015)에서 작업 흐름 서브-시스템(375)은 요청 상태를 업데이트한다. 블록(2010)에서의 결정은 블록(2005)에서 수신된 정보에 기초할 수 있다.
보충 알림 작업 흐름(2020)이 포함될 수 있다. 보충 작업 흐름(2020)은 상태 업데이트 블록(2015) 이후 블록(2025)에서 시작할 수 있다. 블록(2025)에서, 작업 흐름 서브-시스템(375)은 도 1에 도시된 다른 시스템에 "환불 완료" 상태를 알린다. 그리고 메시지가 블록(2030)에서 결정된 바와 같이 허용되고 블록(2035)에서 결정된 바와 같이 요청되는 경우, 블록(2040)에서 작업 흐름 서브-시스템(375)은 상태 업데이트와 함께 메시지를 소비자에게 전송한다. 블록(2030, 2035)에서의 결정은 외부 데이터 소스(370)로부터 각각의 정보를 검색함으로써 작업 흐름 서브-시스템(375)에 의해 수행된다.
도 21은 개시된 실시예에 따른, 취소 철회 작업 흐름(2100)을 포함하는 블록의 예시적인 배열을 나타낸다. 도 3a-d에 도시된 바와 같이 작업 흐름(2100)은 작업 흐름 서브-시스템(375)에 의해 수행될 수 있고 다른 시스템과의 통신에 의존할 수 있다. 작업 흐름(2100)은 블록(2105)에서 시작할 수 있다. 블록(2105)에서, 작업 흐름 서브-시스템(375)은 블록(2105)에서 철회 요청을 확인하고, 요청이 실제로 외부 데이터 소스(370)로부터 각각의 정보를 검색함으로써 작업 흐름 서브-시스템(375)에 의해 블록(2110)에서 결정된 철회 요청인 경우, 블록(2115)에서 주문 취소 요청을 철회하려고 시도한다. 블록(2120)에서 주문이 성공적으로 취소되지 않으면, 블록(2125)에서 작업 흐름 서브-시스템(375)은 철회 요청을 실패로 표시한다. (1) 블록(2120)에서, 작업 흐름 서브-시스템(375)은, 외부 데이터 소스(370)로부터의 데이터에 기초하여, 요청이 철회 요청으로 잘못 표시되었거나(2110) 주문이 취소된 후 또는 (2) 블록(2125)에서 실패로 표시된 경우, 작업 흐름 서브-시스템(375)은 보충 알림 작업 흐름(2135)에 의존하여 알림을 전송할 수 있다.
보충 통지 작업 흐름(2135)은 블록(2140)에서 시작할 수 있다. 블록(2140)에서, 작업 흐름 서브-시스템(375)은 취소 티켓 철회를 알린다. 추가적으로, 작업 흐름 서브-시스템(375)은 블록(2145)에서 취소 철회를 도 1에 도시된 시스템에 알릴 수 있으며, 예를 들어 이는 풀필먼트를 재개하기 위해 행해질 수 있다.
도 22는 개시된 실시 예에 따른, 반환 철회 작업 흐름(2200)을 포함하는 블록의 예시적인 배열을 나타낸다. 도 3a-d에 도시된 바와 같이 작업 흐름(2200)은 작업 흐름 서브-시스템(375)에 의해 수행될 수 있고 다른 시스템과의 통신에 의존할 수 있다. 작업 흐름(2200)은 블록(2205)에서 시작할 수 있다. 블록(2205)에서, 작업 흐름 서브-시스템(375)은 요청이 일괄 철회 요청인지 확인할 수 있으며, 이와 같은 맥락에서 일괄 요청은 예를 들어 다수의 아이템의 반환을 위한 것일 수 있다. 요청이 실제로 일괄 요청이면, 작업 흐름 서브-시스템(375)은, 예를 들어 해외 또는 3PL 판매자가 있는지 확인함으로써, 블록(2210)에서 일괄 처리에 대한 적격성을 확인할 수 있다. 요청이 일괄 요청이 아니거나 적격성이 확인되면, 작업 흐름 서브-시스템(375)은 블록(2215)에서 반환 철회를 처리하고 취소 세부 사항을 SAT 시스템(101)에 전송함으로써 블록(2220)에서 주문의 회수를 취소할 수 있다. 블록(2225)에서 SAT 시스템(101)이 취소가 실패라고 보고하면, 작업 흐름 서브-시스템(375)은 블록(2230)에서 회수 실패로 표시할 수 있다.
보충 알림 작업 흐름(2235)이 포함될 수 있다. 보충 작업 흐름(2235)은 블록(2225)에서 회수 취소 또는 블록(2230)에서 회수에 실패한 후 블록(2240)에서 시작할 수 있다. 블록(2240)에서, 작업 흐름 서브-시스템(375)은 도 1에 도시된 시스템에 반환 요청의 철회 및 적절하다면 블록(2245)에서 회수의 취소를 알린다. 추가적으로, 회수에 실패하고 블록(2230)으로부터의 정보에 기초하여 블록(2250)에서 결정된 바와 같이 요청이 철회에 대한 자동 요청이면, 작업 흐름 서브-시스템(375)은 블록(2055)에서 실패한 회수의 소비자에게 메시지를 전송한다.
도 23은 개시된 실시예에 따른, 교환 철회 작업 흐름(2300)을 포함하는 블록의 예시적인 배열을 나타낸다. 도 3a-d에 도시된 바와 같이 작업 흐름(2300)은 작업 흐름 서브-시스템(375)에 의해 수행될 수 있고 다른 시스템과의 통신에 의존할 수 있다. 작업 흐름(2300)은 블록(2305)에서 시작할 수 있다. 블록(2305)에서, 작업 흐름 서브-시스템(375)은 블록(2305)에서 교환 철회 요청을 수신한다. 블록(2310)에서, 작업 흐름 서브-시스템(375)은 외부 데이터 소스(370)로부터 아이템 정보를 검색하고, 아이템이 3PL이 아니면 블록(2315)에서 회수를 철회하도록 SAT 시스템(101)에 요청한다. SAT 시스템(101)이 블록(2320)에서 회수를 철회하는데 실패했다고 보고하면, 작업 흐름 서브-시스템(375)은 블록(2325)에서 교환 철회 요청을 실패로 표시한다. 그렇지 않으면, 작업 흐름(2300)은 보충 알림 작업 흐름(2330)을 종료하거나 시작할 수 있다. 보충 알림 작업 흐름은 도 13을 참조하여 개시된 보충 작업 흐름(1350)과 동일한 빌딩 블록에 기초하며, 교환 후 프로세스가 아닌 교환 철회의 맥락에서 적용된다는 점만이 다르다. 특히, 작업 흐름(2330)에서 블록(2335, 2340, 2345)은 도 13에 설명된 바와 같이 작업 흐름(1350)의 작업 흐름의 블록(1355, 1360, 1365)과 실질적으로 동일하게 동작한다. 블록(2350)은 작업 흐름(2020)의 블록(2035)과 실질적으로 동일하다. 블록(2355)에서, 작업 흐름 서브-시스템(375)은 교환 철회에 대한 상태 업데이트와 함께 메시지를 소비자에게 전송한다.
본 개시는 그 특정 실시예를 참조하여 도시되고 설명되었지만, 본 개시는 다른 환경에서, 변경없이, 실시될 수 있음을 이해할 것이다. 전술한 설명은 예시의 목적으로 제시되었다. 그것은 개시된 정확한 형태나 실시예에 대해 총망라된 것이 아니며 이것으로 한정되는 것은 아니다. 개시된 실시예의 설명 및 실시를 고려하는 것으로부터 변경 및 조정이 통상의 기술자에게 명백할 것이다. 추가적으로, 비록 개시된 실시예의 형태가 메모리에 저장되는 것으로서 설명되었지만, 통상의 기술자는 이들 형태가 2차 저장 디바이스, 예를 들면, 하드디스크나 CD ROM, 또는 다른 형태의 RAM이나 ROM, USB 매체, DVD, 블루레이, 또는 다른 광 드라이브 매체와 같이, 다른 형태의 컴퓨터 판독 가능한 매체에 저장될 수도 있는 것을 이해할 것이다.
상술한 설명 및 개시된 방법에 기초한 컴퓨터 프로그램은 숙련된 개발자의 기술 내에 있다. 여러 프로그램 혹은 프로그램 모듈은 통상의 기술자에게 알려진 어느 기술을 이용하여 생성되거나, 또는 기존의 소프트웨어와 연결하여 설계될 수 있다. 예를 들면, 프로그램 섹션 혹은 프로그램 모듈은 닷넷 프레임워크, 닷넷 컴팩트 프레임워크(및 비주얼 베이식, C 등과 같은, 관련 언어), 자바, C++, 오브젝티브 C, HTML, HTML/AJAX 조합, XML, 또는 자바 애플릿이 포함된 HTML 내에서 혹은 그것들에 의해서 설계될 수 있다.
게다가, 여기에서는 예시적인 실시예가 설명되었지만, 본 개시에 기초하여 통상의 기술자가 이해할 수 있는 바와 같이, 일부 또는 모든 실시예의 범위는 동등한 요소, 변경, 생략, 조합(예로써, 여러 실시예에 걸치는 형태의 조합), 조정 및/또는 수정을 가질 수 있다. 청구범위 내의 제한 사항은 그 청구범위 내에 적용된 언어에 기초하여 폭넓게 이해되도록 하는 것이며, 응용의 수행 동안 혹은 본 명세서 내에 설명된 예시로 한정되는 것은 아니다. 그 예시는 비배타적으로 해석되도록 하기 위한 것이다. 추가로, 개시된 방법의 스텝은 어떤 다른 방법으로 변경되거나, 스텝을 재배열 및/또는 스텝을 삽입하거나 삭제하는 것을 포함할 수 있다. 그러므로, 설명 및 예시는 오직 예시적으로 고려되는 것이며, 진정한 범위 및 기술 사상은 다음의 청구범위 및 그 동등한 전체 범위에 의해 나타내지는 것으로 의도된다.

Claims (20)

  1. 작업 흐름 편집을 위한 컴퓨터 구현 시스템으로서,
    인스트럭션들을 저장하는 메모리; 및
    동작들을 수행하기 위해 상기 인스트럭션들을 실행하도록 설정된 적어도 하나의 프로세서를 포함하고, 상기 동작들은:
    그래픽 사용자 인터페이스에 기존 작업 흐름을 표시하고, 상기 작업 흐름은 복수의 블록들을 포함함,
    사용자로부터 상기 복수의 블록들에 대한 편집을 수신하고, 편집은 적어도 개별 블록 또는 상기 복수의 블록들 간의 상호 연결에 대한 편집을 포함함,
    상기 수신된 편집에 기초하여 수정된 작업 흐름을 생성하고,
    상기 시스템 내에서 상기 기존 작업 흐름을 대체하기 위해 상기 수정된 작업 흐름을 전파하고, 및
    상기 수정된 작업 흐름을 상기 그래픽 사용자 인터페이스에 표시하는 것을 포함하는 시스템.
  2. 청구항 1에 있어서,
    상기 기존 작업 흐름은 취소 작업 흐름인 시스템.
  3. 청구항 2에 있어서,
    상기 복수의 블록들은 동작들 중 적어도 하나를 수행하기 위한 인스트럭션들을 포함하고, 상기 동작들은:
    결제 전에 주문이 취소되었는지 여부를 결정하고;
    프로모션이 상기 주문에 적용되는지 여부를 결정하고;
    상기 주문의 유형을 결정하고;
    취소를 승인하거나 거절하고;
    상기 취소 요청의 기록을 생성하는 것을 포함하는 시스템.
  4. 청구항 3에 있어서,
    상기 주문의 유형이 이벤트 티켓이면 상기 복수의 블록들은 동작들 중 적어도 하나를 수행하기 위한 인스트럭션들을 더 포함하고, 상기 동작들은:
    상기 이벤트 티켓을 무효화하고;
    이벤트 장소를 알리고;
    상기 이벤트 티켓 취소를 등록하고;
    상기 이벤트 취소에 대한 영수증을 생성하는 것을 포함하는 시스템.
  5. 청구항 3에 있어서,
    상기 주문의 유형이 제품이면 상기 복수의 블록들은 동작들 중 적어도 하나를 수행하기 위한 인스트럭션들을 더 포함하고, 상기 동작들은:
    상기 제품 취소 정보를 등록하고;
    상기 제품의 현재 풀필먼트 상태를 결정하고;
    반환 작업 흐름을 시작하고;
    상기 제품에 대한 환불을 처리하는 것을 포함하는 시스템.
  6. 청구항 5에 있어서,
    상기 제품이 이행되지 않으면 상기 복수의 블록들은 동작들 중 적어도 하나를 수행하기 위한 인스트럭션들을 더 포함하고, 상기 동작들은:
    풀필먼트에 대한 중지 주문을 생성하고;
    취소를 승인하고;
    상기 제품이 있는 패키지가 떠나지 않도록 하는 것을 포함하는 시스템.
  7. 청구항 1에 있어서,
    상기 기존 작업 흐름은 반환 작업 흐름인 시스템.
  8. 청구항 7에 있어서,
    상기 복수의 블록들은 동작들 중 적어도 하나를 수행하기 위한 인스트럭션들을 포함하고, 상기 동작들은:
    반환을 승인하기 위한 데이터를 검색하고;
    제3 자 반환인지 여부를 결정하고;
    반환 요청을 등록하고;
    소비자 유형을 결정하고;
    무료 반환에 대한 적격성을 결정하고;
    미반환 환불에 대한 적격성을 결정하는 것을 포함하는 시스템.
  9. 청구항 7에 있어서,
    상기 복수의 블록들은 동작들 중 적어도 하나를 수행하기 위한 인스트럭션들을 포함하고, 상기 동작들은:
    반환 후 프로세스를 설정하고;
    풀필먼트 상태를 결정하고;
    회수를 요청하고;
    상기 회수 상태를 확인하고;
    반환을 승인하거나 거절하고;
    주문 취소 작업 흐름을 시작하는 것을 포함하는 시스템.
  10. 청구항 1에 있어서,
    상기 기존 작업 흐름은 교환 작업 흐름인 시스템.
  11. 청구항 10에 있어서,
    상기 복수의 블록들은 동작들 중 적어도 하나를 수행하기 위한 인스트럭션들을 포함하고, 상기 동작들은:
    교환에 대한 데이터를 검색하고;
    교환 요청을 등록하고;
    상기 교환의 이유를 결정하는 것을 포함하는 시스템.
  12. 청구항 11에 있어서,
    상기 교환의 상기 이유는 결함이 있는 아이템이고 복수의 블록들은 동작들 중 적어도 하나를 수행하기 위한 인스트럭션들을 포함하고, 상기 동작들은:
    상기 결함이 있는 아이템이 반환되어야 하는지 여부를 결정하고;
    미반환 환불을 적용하고;
    새로운 주문을 시작하는 것을 포함하는 시스템.
  13. 청구항 1에 있어서,
    상기 기존 작업 흐름은 트래킹 및 수집 작업 흐름인 시스템.
  14. 청구항 13에 있어서,
    상기 복수의 블록들은 동작들 중 적어도 하나를 수행하기 위한 인스트럭션들을 포함하고, 상기 동작들은:
    회수 트래킹 유형을 결정하고;
    교환 회수가 가능한지 여부를 결정하고;
    회수 정보 업데이트를 기록하고;
    교환 배달 요청 여부를 결정하는 것을 포함하는 시스템.
  15. 청구항 13에 있어서,
    상기 복수의 블록들은 동작들 중 적어도 하나를 수행하기 위한 인스트럭션들을 포함하고, 상기 동작들은:
    회수를 위한 재시도 조건을 설정하고;
    상기 재시도 조건을 업데이트하고;
    자동 취소에 대한 적격성을 결정하고;
    취소 작업 흐름을 시작하는 것을 포함하는 시스템.
  16. 청구항 13에 있어서,
    상기 복수의 블록들은 동작들 중 적어도 하나를 수행하기 위한 인스트럭션들을 포함하고, 상기 동작들은:
    반환 전 환불에 대한 적격성을 결정하고;
    상기 반환 전 환불을 거절하고;
    환불을 승인하는 것을 포함하는 시스템.
  17. 청구항 1에 있어서,
    상기 기존 작업 흐름은 환불 및 철회 작업 흐름인 시스템.
  18. 청구항 17에 있어서,
    상기 복수의 블록들은 동작들 중 적어도 하나를 수행하기 위한 인스트럭션들을 포함하고, 상기 동작들은:
    환불에 대한 적격성을 결정하고;
    환불 알림을 발행하고;
    철회 요청에 의해 영향을 받는 보류중인 작업 흐름을 결정하고;
    상기 철회 요청에 기초하여 상기 보류중인 작업 흐름을 취소하는 것을 포함하는 시스템.
  19. 작업 흐름 편집을 위한 컴퓨터 구현 방법으로서,
    그래픽 사용자 인터페이스에 기존 작업 흐름을 표시하고, 상기 작업 흐름은 복수의 블록들을 포함함,
    사용자로부터 상기 복수의 블록들에 대한 편집을 수신하고, 편집은 적어도 개별 블록 또는 상기 복수의 블록들 간의 상호 연결에 대한 편집을 포함함,
    상기 수신된 편집에 기초하여 수정된 작업 흐름을 생성하고,
    상기 시스템 내에서 상기 기존 작업 흐름을 대체하기 위해 상기 수정된 작업 흐름을 전파하고, 및
    상기 수정된 작업 흐름을 상기 그래픽 사용자 인터페이스에 표시하는 방법.
  20. 작업 흐름 편집을 위한 컴퓨터 구현 시스템으로서,
    인스트럭션들을 저장하는 메모리; 및
    동작들을 수행하기 위해 상기 인스트럭션들을 실행하도록 설정된 적어도 하나의 프로세서를 포함하고, 상기 동작들은:
    그래픽 사용자 인터페이스에 반환 작업 흐름을 표시하고, 상기 작업 흐름은 복수의 연속적인 블록들을 포함함, 상기 복수의 블록들은:
    반환을 승인하기 위한 데이터를 검색하기 위한 인스트럭션들을 포함하는 제1 블록;
    제3 자 반환인지 여부를 결정하기 위한 인스트럭션들을 포함하는 제2 블록;
    반환 요청을 등록하기 위한 인스트럭션들을 포함하는 제3 블록;
    소비자 유형을 결정하기 위한 인스트럭션들을 포함하는 제4 블록;
    무료 반환에 대한 적격성을 결정하기 위한 인스트럭션들을 포함하는 제5 블록; 및
    미반환 환불에 대한 적격성을 결정하기 위한 인스트럭션들을 포함하는 제6 블록을 포함함,
    사용자로부터 상기 복수의 블록들에 대한 편집을 수신하고, 편집은 적어도 상기 복수의 블록들에서 블록들 중 하나의 제거를 포함함,
    상기 수신된 편집에 기초하여 수정된 작업 흐름을 생성하고,
    상기 시스템 내에서 상기 기존 작업 흐름을 대체하기 위해 상기 수정된 작업 흐름을 전파하고, 및
    상기 수정된 작업 흐름을 상기 그래픽 사용자 인터페이스에 표시하는 것을 포함하는 시스템.
KR1020217019560A 2020-11-18 2020-12-22 작업 흐름 편집을 위한 시스템 및 방법 KR102548910B1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020237021386A KR20230098375A (ko) 2020-11-18 2020-12-22 작업 흐름 편집을 위한 시스템 및 방법

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US16/951,721 2020-11-18
US16/951,721 US11080636B1 (en) 2020-11-18 2020-11-18 Systems and method for workflow editing
PCT/IB2020/062328 WO2022106883A1 (en) 2020-11-18 2020-12-22 Systems and method for workflow editing

Related Child Applications (1)

Application Number Title Priority Date Filing Date
KR1020237021386A Division KR20230098375A (ko) 2020-11-18 2020-12-22 작업 흐름 편집을 위한 시스템 및 방법

Publications (2)

Publication Number Publication Date
KR20220071144A true KR20220071144A (ko) 2022-05-31
KR102548910B1 KR102548910B1 (ko) 2023-06-29

Family

ID=77063487

Family Applications (2)

Application Number Title Priority Date Filing Date
KR1020217019560A KR102548910B1 (ko) 2020-11-18 2020-12-22 작업 흐름 편집을 위한 시스템 및 방법
KR1020237021386A KR20230098375A (ko) 2020-11-18 2020-12-22 작업 흐름 편집을 위한 시스템 및 방법

Family Applications After (1)

Application Number Title Priority Date Filing Date
KR1020237021386A KR20230098375A (ko) 2020-11-18 2020-12-22 작업 흐름 편집을 위한 시스템 및 방법

Country Status (4)

Country Link
US (2) US11080636B1 (ko)
KR (2) KR102548910B1 (ko)
TW (1) TWI777543B (ko)
WO (1) WO2022106883A1 (ko)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230315978A1 (en) * 2022-03-31 2023-10-05 Docusign, Inc. Form Interface For Document Generation In A Document Management System

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20060048776A (ko) * 2004-09-30 2006-05-18 마이크로소프트 코포레이션 워크플로우 스케줄 저작 툴
JP2009545797A (ja) * 2006-08-03 2009-12-24 アイティーアイ スコットランド リミテッド ワークフロー保証及び認証システム
KR20130116165A (ko) * 2010-06-04 2013-10-23 엠시엘 시스템즈 리미티드 통합된 워크플로우와 데이터베이스 트랜잭션
WO2015095738A1 (en) 2013-12-20 2015-06-25 Wal-Mart Stores, Inc. Systems and methods for sales execution environment

Family Cites Families (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6243092B1 (en) * 1997-12-02 2001-06-05 Aspect Communications Transaction flow editing tool
US6225998B1 (en) * 1997-12-02 2001-05-01 Aspect Communications Visual design of workflows for transaction processing
US7177825B1 (en) * 1999-05-11 2007-02-13 Borders Louis H Integrated system for ordering, fulfillment, and delivery of consumer products using a data network
WO2001075691A2 (en) * 2000-03-31 2001-10-11 Mdsi Mobile Data Solutions Inc. Finding technique for a scheduling system
US20030182245A1 (en) * 2000-09-09 2003-09-25 Dong-Seok Seo Internet commerce system and the method
US7249044B2 (en) * 2000-10-05 2007-07-24 I2 Technologies Us, Inc. Fulfillment management system for managing ATP data in a distributed supply chain environment
US6895573B2 (en) * 2001-10-26 2005-05-17 Resultmaker A/S Method for generating a workflow on a computer, and a computer system adapted for performing the method
US7818219B2 (en) * 2001-12-27 2010-10-19 American Hungarian Technologies Inc. Electronic realty and transaction system and method therein
US20030233374A1 (en) * 2002-03-14 2003-12-18 Ulrich Spinola Dynamic workflow process
US20040117528A1 (en) * 2002-08-13 2004-06-17 Jonathan Beacher System and method for selecting and reserving items
US7707055B2 (en) * 2003-09-12 2010-04-27 Altisource Solutions S.A.R.L. Method and system for vendor management
US7631291B2 (en) * 2004-10-01 2009-12-08 Microsoft Corporation Declarative representation for an extensible workflow model
US20060095473A1 (en) * 2004-10-23 2006-05-04 Data Management Associates, Inc. System and method of orchestrating electronic workflow automation processes
EP1851705A4 (en) * 2005-02-17 2009-07-22 Shopmedia Inc PROCESS AND DEVICES FOR SELLING SHIPPING SERVICES ONLINE THROUGH THE WEBSITE OF A TRANSFERER
WO2007064939A2 (en) 2005-12-01 2007-06-07 Avery Dennison Corporation System and method of managing a ticket order
US20070143736A1 (en) * 2005-12-09 2007-06-21 Microsystems Technology, Inc. Workflow Development Platform
GB2466597B (en) * 2007-09-20 2013-02-20 Kyos Systems Inc Method and apparatus for editing large quantities of data extracted from documents
US9401051B2 (en) * 2010-06-23 2016-07-26 Varian Medical Systems International Ag Mechanism for dynamically propagating real-time alterations of medical images
US20120109772A1 (en) * 2010-11-03 2012-05-03 Microsoft Corporation Integrated cloud based marketplace services
US8660881B2 (en) * 2010-12-03 2014-02-25 Salesforce.Com, Inc. Mechanism for facilitating dynamic visual workflow and task generation in an on-demand services environment
US20120310699A1 (en) * 2011-06-02 2012-12-06 Siemens Corporation Approach and tool blending ad-hoc and formal workflow models in support of different stakeholder needs
US9395959B2 (en) * 2011-12-09 2016-07-19 Microsoft Technology Licensing, Llc Integrated workflow visualization and editing
US20140082095A1 (en) * 2012-09-17 2014-03-20 Helen Y. Balinsky Workflow monitoring
US20160012465A1 (en) * 2014-02-08 2016-01-14 Jeffrey A. Sharp System and method for distributing, receiving, and using funds or credits and apparatus thereof
US9697548B1 (en) * 2014-02-20 2017-07-04 Amazon Technologies, Inc. Resolving item returns of an electronic marketplace
TWI636410B (zh) * 2017-05-09 2018-09-21 兆豐國際商業銀行股份有限公司 電子簽核系統及其方法
CN107590070B (zh) 2017-08-18 2020-07-24 深圳怡化电脑股份有限公司 一种业务流程调试方法及装置
WO2020013910A1 (en) * 2018-07-12 2020-01-16 Applied Materials, Inc Constraint programming using block-based workflows
US11593806B2 (en) * 2019-03-25 2023-02-28 Yuh-Shen Song Illicit proceeds tracking system

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20060048776A (ko) * 2004-09-30 2006-05-18 마이크로소프트 코포레이션 워크플로우 스케줄 저작 툴
JP2009545797A (ja) * 2006-08-03 2009-12-24 アイティーアイ スコットランド リミテッド ワークフロー保証及び認証システム
KR20130116165A (ko) * 2010-06-04 2013-10-23 엠시엘 시스템즈 리미티드 통합된 워크플로우와 데이터베이스 트랜잭션
WO2015095738A1 (en) 2013-12-20 2015-06-25 Wal-Mart Stores, Inc. Systems and methods for sales execution environment

Also Published As

Publication number Publication date
TW202221585A (zh) 2022-06-01
TWI777543B (zh) 2022-09-11
US11080636B1 (en) 2021-08-03
US11593742B2 (en) 2023-02-28
US20220156654A1 (en) 2022-05-19
KR20230098375A (ko) 2023-07-03
WO2022106883A1 (en) 2022-05-27
KR102548910B1 (ko) 2023-06-29

Similar Documents

Publication Publication Date Title
KR102548216B1 (ko) 비용 최적화된 구성을 생성하기 위한 패키지 구성의 시뮬레이션을 위한 시스템 및 방법
KR102523033B1 (ko) 프로세스 능률화와 확장성 향상을 위해 선택 요청을 쪼개기 위한 시스템 및 방법
KR102467500B1 (ko) 비동기적으로 큐에 더해진 요청의 오류를 검출하는 시스템 및 방법
US20220198377A1 (en) Systems and methods for automated information collection and processing
KR102548910B1 (ko) 작업 흐름 편집을 위한 시스템 및 방법
KR102422808B1 (ko) 반환 사기 감지 및 예방을 위한 시스템 및 방법
KR102402074B1 (ko) 이벤트 저장 관리를 위한 시스템 및 방법
KR102516606B1 (ko) 리소스를 보존하기 위하여 영구 데이터 요청을 관리하는 시스템 및 방법
KR102501140B1 (ko) 확장성을 개선하기 위해 선택 프로세스를 간소화하는 시스템 및 방법
TWI839610B (zh) 偵測與避免退貨詐欺之系統以及方法

Legal Events

Date Code Title Description
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right