KR20010085823A - 분산된 공급망 설계 환경에서 ａｔｐ 데이터를 관리하기위한 시스템 및 방법 - Google Patents

분산된 공급망 설계 환경에서 ａｔｐ 데이터를 관리하기위한 시스템 및 방법 Download PDF

Info

Publication number
KR20010085823A
KR20010085823A KR1020017003529A KR20017003529A KR20010085823A KR 20010085823 A KR20010085823 A KR 20010085823A KR 1020017003529 A KR1020017003529 A KR 1020017003529A KR 20017003529 A KR20017003529 A KR 20017003529A KR 20010085823 A KR20010085823 A KR 20010085823A
Authority
KR
South Korea
Prior art keywords
atp
parts
request
server
lfm
Prior art date
Application number
KR1020017003529A
Other languages
English (en)
Inventor
케네디브리안엠.
토마스스탠톤엘.
조이너헐버트브이.
Original Assignee
샌제이브 사이두
아이2 테크놀러지즈, 인크.
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 샌제이브 사이두, 아이2 테크놀러지즈, 인크. filed Critical 샌제이브 사이두
Publication of KR20010085823A publication Critical patent/KR20010085823A/ko

Links

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

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Educational Administration (AREA)
  • Game Theory and Decision Science (AREA)
  • Development Economics (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • General Factory Administration (AREA)

Abstract

분산된 공급망 설계 환경에서 ATP 데이터를 관리하기 위한 이행 서버(16)는 복수의 클라이언트들(12) 중 하나로부터 ATP 요청(30)을 수신한다. 상기 ATP 요청(30)은 원하는 제품에 각각 대응하는 복수의 요청 품목을 포함한다. 그런 다음 이행 서버(16)는 상기 요청 품목에 기초하여 하나 이상의 부품 ATP 요청(32)을 생성하고, 부품 ATP 요청(32)을 복수의 로컬 이행 관리자들(14) 중 적어도 하나로 전송한다. 응답으로, 이행 서버(16)는 로컬 이행 관리자(14)로부터 부품 견적(34)을 수신하고, 각각 부품 견적(34)은 부품 ATP 요청(32)에 대응하고 대응하는 원하는 제품에 대한 제품 가용성 정보를 포함한다. 이행 서버(16)는 부품 견적(34)에 따라서 모든 원하는 제품에 대한 제품 가용성 정보를 포함하는 견적(36)을 생성하고, 이 견적(36)을 클라이언트(12)로 전송한다.

Description

분산된 공급망 설계 환경에서 ＡＴＰ 데이터를 관리하기 위한 시스템 및 방법 {SYSTEM AND METHOD FOR MANAGING ATP DATA IN A DISTRIBUTED SUPPLY CHAIN PLANNING ENVIRONMENT}
대형이며 복잡한 공급망은 통상적으로 복수의 설계 조직(planning organization)에 의해 관리되고, 각 공급망은 이 조직 요구에 적절한 하나 이상의 설계 엔진(planning engine)들을 지원한다. 예를 들면, 일부 조직은 공급망 설계자(supply chain planner, SCP) 엔진을 지원할 수도 있고, 다른 조직은 공장 설계(factory planner, FP) 엔진을 지원할 수도 있으며, 또 다른 조직은 다른 형태의 설계 엔진을 지원할 수도 있다. 결과적으로, 공급(supply)과 수요(demand)의 일치, 제품 할당(product allocation), 및 다른 계약 태스크(promising task)와 이행 태스크(fulfillment task)는 논리적이거나 지리적으로 분산된 다양한 설계 엔진을 이용하여 관리될 것이다. 이것은 고객과 공급자에게 비슷한 많은 문제들이 발생시킨다.
확장된 공급망 동작(operations)에 대한 상세한 가시도(visibility)의 부족은, 흔히 회사가 정확한 인도 날짜를 얘기해주고(quoting) 시기 적절한 방식으로 고객 주문을 충족시킬 수 없도록 한다. 비록 적절한 가시도가 존재하더라도, 선단(front-end)과 후단(back-end)의 거래 대상물들(business objectives)간의 통합(integration)이 잘 이루어지지 않으면 용량(capacity)을 증가시켜도 낮은 이윤(margin)의 제품을 초래할 수 있으므로, 중요한 시장 채널이 다소 중요하지 않은 시장 채널(market channel)과 최적화가 덜 이루어진 다른 서브-최적 매매 계약(sub-optimal commitment)보다도 질 낮은 서비스를 받는다. 또한, 일단 인도 날짜 및 다른 매매 계약이 이루어지면, 예측하지 못한 공급 및 수요 변화의 영향을 정하기 위하여 생산 및 로지스틱스 이행 프로세스(production and logistics execution process)를 통해 이 매매 계약을 감시할 필요가 있다. 따라서, 분산된 공급망 설계 환경에서, 주문을 계약하고(promising) 이행하기 위하여 고객과 연결된 하나의 동일한 인터페이스가 필요하다. 이런 성능을 제공하지 못하면 주문 접수율(order capture rate), 인도 이행, 및 재고(inventory), 주문 처리, 및 다른 동작(activity)과 연관된 관리비용(administrative cost)에 부정적으로 영향을 준다.
최근의 수많은 시도에도 불구하고, 분산된 공급망 설계 환경에서 컴퓨터망을 통해 주문 계약 태스크(order promising task) 및 주문 이행 태스크(order fulfillment task)를 관리하기 위한 효율적인 솔루션(solution)을 성공적으로 만들지 못했다. 몇몇 회사가 만족스러운(acceptable) 전단(front-end) 솔루션 또는 "고객 중심(customer-centric)" 솔루션을 개발했지만, 다른 회사들은 적당한 후단(back-end) 공급망 최적화 솔루션을 개발하기 위하여 많은 에너지를 쏟아 부여야 하며, 이 분산된 공급망 설계 환경에서 주문 계약 태스크와 주문 이행 태스크를 효율적으로 관리하기 위해 이러한 선단 솔루션과 후단 솔루션을 성공적으로 통합한 것은 없었다. 결과적으로, 예를 들어 회사는 일상적으로(routinely) 계약을 과도하게 해야 되며, 일반적으로 혼합된 성과(mixed success) 때문에, 회사가 체결한 매매 계약을 만족시키기 위해 비용(money)을 낭비한다. 성장하는 전 세계적인 인터넷 기반 경제(global Internet-based economy)에서 효율적으로 경쟁하기 위해, 회사들은 정확한 매매 계약을 할 수 있어야 하고, 회사의 거래 객체와 제휴(align)할 수 있어야 하며, 효율적이고 유리한 방식으로 자신들의 매매 계약을 충족시켜야 한다.
또한, 다자간 기업들의 노력으로, 공급망을 통하여 시스템을 완벽하게 배치하는 것은 종종 경제적으로 또는 적어도 정책적으로 불가능하다. 그래서, 최적의 상황에서 일상적으로 배치되는 솔루션 시스템을 위하여, 보다 정교한 배치 시스템이 순차적으로 도입되는 동안 시스템의 성능을 확장시키는 등 현존하는 시스템을 조정할 수 있는 성능을 구비해야 한다. 이 솔루션 시스템은 결국 이런 현존하는 시스템이나 배치 시스템과 생산적으로 공존할 수 있어야 한다. 주문 계약 및 주문 이행을 관리하기 위한 기존의 기술은 이러한 요구를 충족시키기에는 부적절하다.
본 발명은 일반적으로 공급망 설계 분야(supply chain planning)에 관한 것으로, 더욱 상세하게는 분산된 공급망 설계 환경에서 주문 이행(order fulfillment)을 관리하기 위한 시스템 및 방법에 관한 것이다.
도 1은 본 발명에 따른 분산된 공급망 설계 환경(distributed supply chain planning environment) 내에서 매매 계약(commitment)을 충족시키기 위한 예시적인 실시예를 도시하는 도면.
도 2는 본 발명에 따른 예시적인 ATP 요청 작업흐름을 도시하는 도면.
도 3은 본 발명에 따른 예시적인 견적(quotation) 확인 작업흐름을 도시하는 도면.
도 4는 본 발명에 따른 예시적인 계약(promise) 수락 작업흐름을 도시하는 도면.
도 5는 본 발명에 따른 예시적인 부품(component) 계약 변경을 도시하는 도면.
본 발명에 따라서, 분산된 공급망 환경 내에서 공급망 설계 및 주문 이행과연관된 단점 및 문제점들은 실질적으로 감소되거나 제거된다.
본 발명의 일 실시예에 따르면, 계약 체결이 가능한지에 관한 데이터인 ATP(available-to-promise) 데이터를 관리하기 위한 시스템은 클라이언트 인터페이스(client interface)와 ATP 서버 인터페이스(ATP server interface)를 포함한다. 이행 서버(fulfillment server)는 상기 클라이언트 인터페이스를 이용하여, 원하는 제품(product)에 각각 대응하는 복수의 요청 품목(request line-item)을 포함하는 제1 ATP 요청(request)을 수신한다. 이 이행 서버는 이 요청 품목에 기초하여 하나 이상의 부품 ATP 요청을 발생시키고 이 ATP 서버 인터페이스를 이용하여 복수의 ATP 서버 중 적어도 하나로 이 부품 ATP 요청을 전송한다. 이 이행 서버는 상기 ATP 서버 인터페이스를 이용하여 각각 부품 ATP 요청에 대응하고 하나 이상의 원하는 대응 제품에 대한 제품 가용성 정보(product availability information)를 포함하는 복수의 부품 견적(componet quotations)을 상기 ATP 서버로부터 수신한다. 또한, 이행 서버는 상기 부품 견적에 의해 제공된 제품 가용성 정보에 따라 정해진 견적을 생성하며, 클라이언트 인터페이스를 이용하여 상기 견적을 전송한다.
본 발명의 다른 실시예에 따르면, 로컬 이행 관리자(local fulfillment manager, LFM)는 연관된 ATP 서버를 구비하고 다른 LFM을 포함하는 분산된 공급망 환경에서 동작한다. 이 LFM은 이행 서버 인터페이스와 ATP 서버 인터페이스를 포함한다. 이 LFM은 각각 원하는 제품에 대한 특정 ATP 요청 품목에 대응하는 하나 이상의 부품 ATP 요청을 이행 서버로부터 수신한다. 또한 LFM은 연관된 ATP 서버를 이용하여 각 요청 품목에 대한 ATP 응답(response)을 결정하고 상기 대응하는ATP 응답에 따라 각 요청 품목에 대한 부품 견적을 생성한다. 부품 견적은 원하는 대응 제품에 대한 제품 가용성 정보를 포함한다.
그런 다음, LFM은 하나 이상의 다른 LFM으로부터의 다른 부품 견적과 통합(consolidation)하기 위하여 이행 서버로 상기 부품 견적을 전송한다.
본 발명은 중요한 기술적인 장점을 제공하다. 본 발명의 이행 서버 및 LFM은 특정된 이용자, 고객, 공급자, 다른 소정의 거래 제약조건에 따라서 잠재적으로 많은 수의 클라이언트로부터 복잡한 복수의 품목 ATP 요청에 대한 주문 계약 및 이행을 동시에 그리고 지능적으로(intelligently) 관리할 수 있다. ATP 서버가 예를 들어 전 인터넷에, 서로 그리고 이행 서버로부터 지리적으로 분산될 경우, 본 발명의 장점은 특히 명확해진다. 게다가, 이런 ATP 서버가 다른 조직(corporate) 내에 존재할 경우, 이행 서버는 이전엔 불가능했던 주문 계약과 이행 성능에 대한 기초를 확립한다. 본 발명은 또한 ATP 제품 할당량, 자재(material) 가용성, 또는 전 세계에 걸친 ATP 서버 및 관련 설계 엔진의 용량 가용성에 의지하고 영향을 미치는 ATP 요청, 견적 확인, 계약 수락을 위해 단일 인터페이스를 클라이언트에게 제공한다. 이것은 다른 이익들 가운데에서도, 확장된 공급망 동작 내에서 매우 바람직한 가시도를 제공한다.
본 발명은 대역폭을 최대로 하고 대기 시간(latency)을 최소로 하도록 이행 서버와 LFM 사이에 필요한 통신을 최소로 하므로, (다수의 품목 인도를 위해 온라인 고객에게 즉시(instant) 견적을 제공하는 인터넷 웹 사이트와 같은) 대화형 시스템(interactive system) 및 다른 점에서(otherwise)는 불가능한 다른 애플리케이션에서 본 발명의 이용을 지원한다. 본 발명은 적절히(as appropriate) 이행 서버, LFM, 또는 ATP 서버 내에서 현명하고 탄력성 있게 계산 동작을 배치시키고, 동시에 많은 옵션을 포함할 수 있는 풍부한 응답을 전송하도록 LFM 인터페이스를 설계하여(engineer) 일부 이것을 달성한다. 이 일관된(consistent) LFM 인터페이스는 본 발명에 의해 제공된 확장된 특성, 동작, 및 구조를 지원하도록 원래 설계되지 않은 현존의 ATP 서버 및 유사한 시스템을 조정(accommodation)할 수 있도록 하는 것 등과 같이 매우 다양한 ATP 서버를 동시에 지원할 수 있도록 한다.
또한, 본 발명의 시스템 구조는 특정 애플리케이션용에 적절하게 성능을 최적하기 위하여 소정의 계산 동작이 이루어지는 상이한 환경에서 변경될 필요가 있다는 것을 고려한다. 예를 들어, 소정 애플리케이션은 매우 높은 처리율(throughput)을 갖는 시스템을 필요로 할 수 있지만 긴 대기 시간을 허용할 수 있고, 반면에 다른 것은 매우 짧은 대기 시간을 요구하지만 보다 적은 처리율을 허용할 수 있다. 한편, 소정 애플리케이션은 엄청난 양의 제품을 지원할 필요가 있을 수 있지만, 다른 것은 각 제품에 대한 공급자의 거대한 네트워크를 지원할 필요가 있을 수 있다. 또한 또 다른 것은 커다란 판매자 네트워크를 필요로 할 수 있다. 본 발명은 이런 다양한 요청을 지원할 수 있는 적절한 탄력성을 제공한다. 해당 분야의 당업자는 첨부한 도면, 상세한 설명, 및 청구범위로부터 다른 기술적인 장점을 용이하게 이해할 것이다.
첨부한 도면을 참조로 기재된 다음의 상세한 기재를 참조하면, 본 발명을 좀더 완벽하게 이해할 수 있고, 본 발명의 추가적인 특징 및 장점들을 이해할 수 있을 것이다.
도 1은 분산된 공급망 설계 환경에서 매매 계약(commitment)을 이행하기 위한 예시적인 시스템(10)을 도시한다. 이 시스템(10)은 적절한 전사적 자원 관리(enterprise resource planning, ERP) 시스템, 판매력 자동 조절(sales force automation, SFA) 시스템, 주문 관리 시스템(order management system, OMS), 및 다른 소정의 적당한 시스템을 나타내는 하나 이상의 클라이언트(12)를 포함한다. 각 클라이언트(12)는 한 명 이상의 고객, 이용자, 또는 다른 기업(entity)과 연관될 수 있다. 특정 실시예에서, 클라이언트(12)는 자신들이 갖고 있는 주문계약(promising)과 이행 성능(capability)을 증대시키거나 대체시킬 수 있는 판매 및 고객 서비스 지향 애플리케이션(sales and service oriented applications)을 포함할 수 있다. 클라이언트(12)는 애플리케이션-지정 통합 계층(application-specific integration layer)(도시하지 않음)을 이용하여 이행 서브(16)와 통신하고 상호 작용한다(interact). 이 애플리케이션-지정 통합 계층은 클라이언트(12), 이행 서버(16), 또는 클라이언트(12)와 이행 서버(16) 모두에서 동작하는 애플리케이션 프로그래밍 인터페이스(application programming interface, API), 객체 요청 브로커(object request broker, ORB), 또는 다른 적당한 소프트웨어 인터페이스를 포함할 수 있다. 네트워크(18)는 클라이언트(12)를 이행 서버(16)에 연결시키고, 근거리 통신망(local area network, LAN), 대도시 지역 통신망(metropolitan area network, MAN), 광역 종합 통신망(wide area network, WAN), 인터넷(Internet)과 같은 글로벌 네트워크(global network), 또는 다른 적당한 네트워크나 네트워크들의 집합(collection)일 수 있다.
ATP(available-to-promise) 서버(14)는 다른 것들 중에서, 부품 견적의 형태로 부품 ATP 요청에 대한 제품 가용성 응답을 제공할 수 있는 설계 엔진(planning engine)을 각각 지원하고, 이 설계 엔진과 연관된다. ATP 서버(14)에 연관된 하나 이상의 설계 엔진은 또한 가격책정(pricing) 및 다른 적절한 부가적인 성능을 제공할 수 있다. 각 ATP 서버(14)에 위치하거나 각 ATP 서버(14)와 연관된 로컬 이행 관리자(local fulfillment manager, LFM)(22)는 ATP 서버(14)와 이행 서버(16) 사이의 상호 작용(interaction)을 관리한다. 일 실시예에서, LFM(22)은 시스템(10)내에서의 주요 의무(primary responsibility)가 적당한 포맷(format)으로 ATP 서버(14)로부터 또는 ATP 서버(14)로 부품 요청, 부품 견적, 부품 견적 확인, 및 부품 계약을 전송 받거나 전송하고, 주문 이행 시점에서 이들의 상태를 감시하는 "씬(thin)" 엔진이다. ATP 서버(14)는 API, ORB을 포함하거나, ATP 서버(14), 이행 서버(16), 또는 ATP 서버(14)와 이행 서버(16) 모두에서 동작하는 다른 적당한 소프트웨어 인터페이스를 포함할 수 있는 애플리케이션-지정 통합 계층(도시하지 않음)을 통해 이행 서버(16)로 서비스를 제공한다. 네트워크(20)는 ATP 서버(14)에 이행 서버(16)를 연결시키고, 네트워크(18)와 통합되거나 네트워크(18)와는 개별적인 LAN, MAN, WAN, 인터넷과 같은 글로벌 네트워크, 또는 네트워크들의 집합일 수 있다.
일 실시예에서, LFM(22)은 각각 이행 서버(16)로 동일한 인터페이스와 기능성(functionality)을 제공하지만, 다른 ATP 서버와 동작하도록 설계될 수 있다. 많은 ATP 서버(14)는 주로 부품 견적을 계산하는 데 이용될 수 있는 주문 ATP 시스템, 이행 시스템, 또는 ERP 시스템일 수 있지만, 시스템(10)과 연관된 것과 같이 좀더 포괄적인 분산 네트워크 환경에서 이행 서버(16)와 동작할 수 있도록 설계될 수는 없다. 심지어, 다른 ATP 서버(14)는 ATP 견적을 제공할 수 있는 성능을 구비할 없고, 오히려 이들 다른 ATP 서버(14)는 ATP 견적을 계산할 때 필요한 정보를 단순히 기억하거나 지원할 수 있다. 다른 경우에, ATP 서버(14)는 이행 서버(16)와 동작하도록 설계될 수 있고, 그것 나름대로 이행 서버(16)의 LFM 인터페이스를 직접 지원하도록 집적된 LFM(22)을 구비할 수 있다.
이러한 경우 각각에서, LFM(22)은 적절히 작성된(form) 부품 견적이나 부품 계약을 계산하고, 최종 수락을 처리하며, 해당 자재(material)나 수량(capacity)을 실제로 확실하게 확보할 책임이 있다. 거의 해야할 필요는 없지만, LFM(22)은 이행 서버(16)의 LFM 인터페이스 및 연관된 ATP 서버(14) 사이에 전송된 정보를 변환할 수 있다. ATP 서버(14)를 좀더 대형인 시스템의 일부로서 작용할 수 있도록 설계하지 않는 다른 상황에서, LFM(22)은 정보의 실질적인 계산이나 다른 조작을 수행해야만 한다. 심지어, ATP용으로 설계되지 않은 시스템과 상호 작용하거나, 시스템의 활동(activity)을 다른 가능한 곳에서 처리할 필요가 있는 다소 저속인 시스템과 상호 작용할 경우, LFM(22)은 몇몇 ATP 기능을 수행할 필요가 있다. 본 발명은 (계산적으로 다소 난해하고(heavier) 복잡한 이행 서버(16)와 별개로 다양한 ATP 서버 변화(variation)를 유지하는) LFM(22)에 다양한 탄력성(flexibility)을 제공하고, 보다 용이하게 배치된 LFM(22)으로 전환(translation)하도록 제한한다(localize).
일반적으로, 클라이언트(12)는 ATP 요청을 이행 서버(16)로 제출하고, 각 요청은 각각 하나 이상의 분산된 ATP 서버(14)에서 ATP일 수 있는 특정 제품에 적합한 하나 이상의 품목을 포함한다. 이행 서버(16)는 LFM 인터페이스와 네트워크(20)를 이용하여 적절한 LFM(22)으로 이러한 품목에 대응하는 부품 ATP 요청을 중개한다(broker). 차례로(in turn) 부품 ATP 요청을 받은 각 LFM(22)은 필요한 계산을 수행하고 필요한 소정의 예약(reservation)이나 변경을 기록하기 위하여 연관된 ATP 서버(14)를 이용한다. LFM(22)은 원래 대응하는 ATP 요청에 적당한이행 서버(16)로 최종 부품 견적을 보낸다. 이 이행 서버(16)는 이 부품 견적을 적절히 처리하고 요청하는 클라이언트(12)로 통합된(unified) 전체 견적을 제시한다.
클라이언트(12)는 이행 서버(15)가 적절히 처리하고, 부품 견적 확인으로서 LFM(22)으로 전송한 이 견적을 전체 또는 일부 수락하기 위해서 견적 확인을 발생시킬 수 있다. 이 부품 견적 확인은 특정 부품 ATP 요청에 대응한다. 자신과 연관된 ATP 서버(14)와 협력하여, LFM(22)은 요청된 제품에 대한 고객과 공급자 사이의 공급을 소비하고 매매 계약을 체결하는 부품 계약을 발생시킨다. LFM(22)과 ATP 서버(14)로부터 수신한 부품 계약에 기초하여, 이행 서버(16)는 대응하는 ATP 요청에 적절한 통합된 계약을 클라이언트(12)에게 제시한다. 클라이언트(12)는 이 계약 전체 또는 계약 일부분을 받아들이기 위한 수락을 발생시킨 후, 이행 서버(16)로 이 수락을 보낼 수 있다. 이 이행 서버(16)는 LFM(22)으로 부품 수락을 보내고, LFM(22)은 부품 수락 확인을 이용하여 이행 서버(16)에 응답하다. 일단, LFM(22)으로부터 받은 부품 수락 확인에 기초하여, 이행 서버(16)가 클라이언트(12)로 통합된 수락 확인을 전송하면, 주문 계약 및 이행 사이클은 완료된다. 시스템(10)의 동작은 다음에 보다 상세히 기술한다.
클라이언트(12), 이행 서버(16), LFM(22), 및 ATP 서버(14)는 각각 하나 이상의 위치에 존재하는 하나 이상의 컴퓨터나 다른 적당한 처리 장치 상에서 동작할 수 있다. 이런 컴퓨터 각각은 적당한 소정의 키패드(keypad), 터치 스크린(toutch screen), 또는 정보를 받아들 일 수 있는 다른 적당한 장치일 수 있는 입력 장치를포함할 수 있다. 출력 장치는 디지털 데이터나 아날로그 데이터, 시각 정보(visual information), 음성 정보(audio information)를 포함하는 적당한 정보를 전달할 수 있다. 이 입력 장치와 출력 장치는 자기 컴퓨터 디스켓(magnetic computer diskette), 씨디-롬(CD-ROM), 또는 컴퓨터로부터 정보를 받고 컴퓨터로 정보를 제공하는 다른 매체와 같은 고정된 소정의 적당한 기억 매체나 제거 가능한(removable) 기억 매체(storage media)를 지원할 수 있다. 하나 이상의 프로세서(processor) 및 관련 휘발성 또는 비휘발성 메모리는 명령을 실행하고, 경우에 따라서, 연관된 클라이언트(12), ATP 서버(14), LFM(22), 또는 이행 서버(16)의 동작에 따라서 정보를 처리한다. 클라이언트(12), 이행 서버(16), LFM(22), 및 ATP 서버(14)는 컴퓨터 소프트웨어, 컴퓨터 하드웨어, 또는 소프트웨어와 하드웨어의 적절한 조합으로 구현될 수 있고, 서로 통합될 수 있거나 개별적으로 구현될 수 있다. 높은 가용성이나 다른 성능(performance) 요구 조건(requirement)들을 지원하기 위하여, 시스템(10)은 특별한 필요(need)에 따라 여분의 클라이언트(12), 이행 서버(16), LFM(22), ATP 서버(14)를 조립하여 설계할 수 있다.
일 실시예에서, 시스템(10)의 각 LFM(22)에 대하여, 이행 서버(16)는 LFM 이름, LFM(22)에 대한 적당한 서술적인 정보, 인터넷 프로토콜(internet protocol, IP), 또는 LFM(22)에 대한 다른 네트워크 어드레스(address), LFM(22)이 실패할 경우 지정된 백업(back-up) LFM(22)의 식별부호(identity), 또는 다른 적당한 정보를 보유할 수 있다. 이행 서버(16)는 소싱(sourcing) 목적을 위하여 ATP 서버 그룹과 계층 정보(hierarchy information)를 보유할 수 있다. ATP 서버 그룹은 예를 들면, 공급자 그룹(supplier group), 가격책정 그룹(pricing group), 지리적인 위치를 모델링할 수 있다. 다음에 좀더 상세하게 기술하는 것처럼, 그룹 선택물(group preference)과 공급자 소싱 선택물(supplier sourcing preference) 모두에 따라서 동작할 수 있기 때문에, 이행 서버(16)는 하나 이상의 공급자를 소정의 응용 가능한 ATP 서버 그룹에 관련시킬 수 있다. 예로서, 클라이언트(12), 또는 연관된 사용자는 이행 서버(16)가 이들 선택물들과 공급자 그룹 매핑(mapping)들에 기초하여 적당한 LFM(22)로 부품 ATP 요청을 보내는(direct) 경우에, 선택된(preferred) 공급자, 선택된 그룹, 또는 이들 둘 다를 명기할 수도 있다. 각 ATP 서버 그룹에 대하여, 이행 서버(16)는 그룹명, 적당한 서술적인 정보, 이 그룹에 대한 부 그룹(parent group), 자 그룹(child group)의 목록, 그룹 내의 LFM(22) 목록, ATP 서버 그룹과 연관된 실제(active) 공급자 목록, 및 다른 소정의 적당한 정보를 보유할 수 있다. 소싱 선택물들은 ATP 서버 그룹 계층 내의 소정 레벨에서 정해질 수 있다.
제품은 클라이언트(12)와 연관된 사용자가 요청할 수 있고, 유형(예를 들면 컴퓨터)이거나 무형(예를 들면, 서비스)이든 무엇이든지 나타낼 수 있다. 제품은 각각 복수의 제품과 관련될 수 있는 품목(item)과 관련된다. 이것은 상이한 가격 시점(point), 리드 타임(lead times), 공급자, 또는 동일한 품목에 대한 다른 적당한 특성을 모델링 할 수 있도록 한다. 부가적으로, 복수의 품목은 동일한 제품에 관련될 수 있다. 이것은 예를 들어, 동일한 제품에 대한 복수의 공급자를 모델링할 수 있도록 한다. 일 실시예에서, 이행 서버(16)는 각 제품에 대하여, 제품명,제품 설명(product description), 치수의 디폴트 단위(default unit of measure, UOM), 디폴트 로트 크기(default lot size) 또는 그 배수(multiple)를 보유할 수 있고, 클라이언트(12) 또는 연관된 사용자가 제품에 대한 주문, 고객-순위(customer-ranked), 공급자 순위(supplier-ranked), 또는 다른 대체물(alternate)이나 대용물(substitute)의 목록, 공급자-지정 관련 제품(supplier-defined related product), 제품에 대한 위치, 제품에 대한 실제 공급자, 스타일(style), 크기, 컬러, 또는 다른 적당한 제품 정보와 같은 제품에 대한 속성 유형을 취소시킬 수 있는 취소 범위(cancellation window)를 보유할 수 있다. 이행 서버(16)는 또한 소정의 특정 제품과 구분되는 속성 유형, 설명, 가치 범위(value range), UOM, 속성 유형 내의 특정 속성, 및 다른 적당한 소정의 속성 정보와 같은 속성에 관한 정보를 보유할 수 있다.
이행 서버(16)는 판매 채널(sale channel)(고객) 및 부-자(parent-child) 또는 판매 채널들 간의 다른 계층 관계를 보유할 수 있다. 이행 서버(16)는 다음에 좀더 상세하게 기술하는 것처럼, 주문 계약과 다른 적당한 목적을 위해 판매 채널을 이용할 수 있다. 일 실시예에서, 이행 서버(16)가 갖고 있는 각 판매 채널에 대한 한정(definition)은 임의의 조합으로, (1) 이름, (2) 설명(description), (3) 카테고리(category), (4) 부(parent), (5) 자(children), (6) 이행 서버(16)가 제품 소싱을 정할 때 이용할 수 있는 우선 그룹이나 그룹의 다른 목록, (7) 고객이 구비하거나 주문할 수 있는 제품, (8) 소정 제품에 대한 우선 그룹이나 그룹의 다른 목적, (9) 각 제품에 대한 우선 공급자나 공급자의 다른 목록, (10) 고객이 일반적으로 또는 소정 제품에 대하여 대체 제품이나 대용 제품을 수락하는지의 여부, (11) 각 제품에 대한 우선 대체물이나 대용물, 또는 대체물이나 대용물의 다른 목록, (12) 고객이 일반적으로 또는 소정 제품에 대하여 대체 소싱 그룹을 수락하는지의 여부, (13) 각 제품에 대한 목표(target) 또는 지정(mandatory) 가격 제한(price limit)이나 가격 범위, (14) 고객이 일반적으로 또는 소정 제품에 대하여 완전 선적(full shipment)만을 선호하는지의 여부, (15) 고객이 일반적으로 또는 소정 제품에 대하여 이행되지 않은 요청의 일부분을 주문잔고(backlog)로서 보유하는(carry) 것보다 취소시키는 것을 선호하는지의 여부, (16) 고객이 일반적으로 또는 소정 제품에 대하여 정시 선적(on-time shipment)만을 선호하여 이전의 계약이나 이후의 계약을 거절하지의 여부, (17) 늦거나 이른(late or early) 선적을 수락하지 않는 범위 이외의 인도 범위(delivery window), (18) 소정 제품에 대하여 로트 크기를 요청하여 이 값에 따라 견적이 마무리되는(rounded) 것, (19) 고객이 일반적으로 요청 품목이 줄어들 경우(short) 논리적으로 연관된 품목도 비례적으로 줄어들게 되는 것을 선호하는지의 여부를 포함하며, 이에 한정되지 않는다.
일반적으로, 할당량 정보는 판매 채널의 소정 레벨이나 다른 계층에 존재하거나 필요한 만큼 깊은(deep) 레벨이나 계층에 존재할 수 있다. 주 그룹(primary group)이나 공급자가 요청을 서비스할 수 없을 경우, 이행 서버(16)는 대체 그룹이나 공급자를 통해 요청 품목을 처리할 수 있다. 선택 그룹(preferred group) 내에서, 공급자 선택물들은 자신들이 규정되면 그대로 받아들다. 대체물 또는 대용물의 목록은 일반적으로 제한되지 않으므로, 수락 견적 응답을 선택된 공급자로부터입수할 수 없을 경우, 이행 서버(16)는 다른 잠재적인(potential) 공급자로부터 제품 할당량이나 재료 또는 수량 가용성(capacity availability)을 정할 수 있다. 대체물이나 대용물을 허용하고, 고객 선택 대체물(customer-preferred altenate)을 특정하지 않은 요청에 대하여, 공급자는 자신이 대체물이나 대용물을 선택하여 응답할 수 있다.
다음에 좀더 상세하게 기술하는 것처럼, 이행 서버(16)는 공급자나 부-자 또는 공급자들 간의 다른 계층적인 관계에 관한 정보를 보유할 수 있고, 이 이행 서버(16)는 주문 계약을 위해 또는 다른 적당한 목적을 위해 이 정보를 이용할 수 있다. 일 실시예에서, 이행 서버(16)에 보유하고 있는 공급자에 관한 한정은 임의의 적당한조합으로, (1) 이름, (2) 설명, (3) 카테고리, (4) 부, (5) 자, (6) 공급자가 제공하는 제품, (7) 이 공급자와 연관된 그룹, (8) 소정 제품에 대한 순위 선택 고객(ranked preferred customer)나 선택 고객의 다른 목록, (8) 소정 제품에 대한 순위 선택 고객이나 선택 고객의 다른 목록, (9) 소정 제품에 대하여 수락 가능한 대체물 또는 대용물, (10) 최대 주문량 및 최소 주문량, (11) 견적의 유효성(validity)에 영향을 미치지 않고 이행 서버(16)가 견적량(quotation quantity)을 감소시킬 수 없도록 하는 주문량 제약조건, (12) 취소 제한(cancellation restriction), (13) 주문을 취소할 수 없는 범위를 제외한 취소 범위를 포함할 수 있고, 이에 한정되지 않는다.
이행 서버(16)는 이미 기술한 거래 제약조건(business constraint)들을 이용하고, 이 거래 제약조건은 미리 기억될 수 있거나, 클라이언트(12)로부터의 ATP 요청에서 얻을 수 있거나, 특정 LFM(22)으로 요청 품목을 소싱하거나, 또는 이러한 제약조건을 만족시키지 않는 LFM(22)으로부터 소정의 부품 견적 및 부분 계약 응답을 제거할 수 있다. 예를 들면, 공급자가 여러 대체 응답, 또는 대체 그룹으로부터의 응답을 제공할 경우, 이행 서버(16)는 순응하지 않은(non-compliant) 응답 또는 수락할 수 없는 그룹으로부터의 응답을 제거할 수 있다. 순응하는 대체물이 없을 경우, 이행 서버(16)는 전체 응답을 거절할 수 있다. 대체물이나 대체 그룹의 목록이 존재한다고 하여 이것들이 이용될 것이라는 것을 의미하는 것은 아니다. 일 실시예에서, 클라이언트(12) 또는 연관된 이용자는 특별한 필요에 따라서 ATP 요청, 견적 확인, 계약 수락을 발생시킬 때 이들 거래 제약조건 일부 또는 모두를 선택적으로 무효로 할 수 있다(override).
일 실시예에서, 이행 서버(16)는 하나 이상의 제품 판매자의 계층을 지원하고, 각 LFM(22)은 이행 서버(16)에 의해 지원된 제품의 서브셋(subset)을 가지고 있지 않은 판매자의 동일한 계층을 지원한다. LFM(22)은 대응하는 제품에 대한 판매자 계층 전체(throughout)의 할당량을 기초로 하여 부품 견적이나 부품 계약을 계산한다. 이러한 성능은 Kennedy 등에 의해 1995년 6월 16일에 출원되어 계류중인 미합중국 특허 출원 번호 제08/491,167호의 "System and Method for Managing Available to Promise(ATP).", Kennedy 등에 의해 1997년 2월 18일에 출원되어 계류중인 미합중국 특허 출원 번호 제08/802,434호의 "System and Method for Managing ATP"에 모두 기술되어 있고, 이들 두 발명은 본 명세서에 모두 참조되어, 본 명세서의 일부를 이룬다. 결과적으로, 시스템(10)은 제품 기준(basis)에 따라서(by) 제품에 대한 제품 할당량을 LFM(22)과 관련 ATP 서버(14)로 분산시킬 수 있는 능력을 제공하여, 많은 제품을 갖고 있는 시스템의 공간 및 시간에 대한 범위성(scalability) 모두를 얻을 수 있다.
이행 서버(16)는 미합중국 특허 출원 번호 제08/802,434호에 기재된 바와 같이 관련 제품 또는 일반 제품(generic product)이 갖고 있는(of) 하나 이상의 계층을 지원한다. LFM(22)은 동일한 계층에 존재하는 하나 이상의 세브셋(subset)을 지원할 수 있고 이런 서브 계층 내의 제품에 관한 할당량에 기초하여 부품 주문이나 부품 계약을 계산할 수 있다. 이것은 계층으로 제품들이 관련되어 있는 애플리케이션에 부가적인 기술적인 장점을 제공한다.
하나 이상의 이행 서버(16)는 서로 협력하거나 독립적으로 동작하거나, 또는 LFM(22)의 동일한 셋트와 함께 동작할 수 있다. 각 LFM(22)은 복수의 이행 서버(16)로부터 부품 ATP 요청 및 부품 견적 확인을 수락할 수 있고, 부품 견적이나 부품 계약을 복수의 이행 서버(16)로 전달할 수 있다. 이것은 많은 기술적인 장점들을 포함하고, 그 장점들 중 하나는 많은 클라이언트나 많은 ATP 요청(30)을 처리하기 위하여 시스템을 조정할 수 있는(scale) 능력을 갖는다는 것이다. 부가적으로, 이 능력은 특별한 필요에 따라서 이행 서버(16)의 지리적인 분산이나 조직적인 분산을 허용할 수 있다.
각 이행 서버(16)는 자신들이 지원하는 한 셋트의 클라이언트(12)에 따라서, 상이한 거래 제약조건을 강요할 수 있다. 각 이행 서버(16)는 상이한 셋트의 LFM(22)과 동작할 수 있고, 각 LFM(22)은 이행 서버(16)에 대응하는 하나 이상의LFM 셋트에 속할 수 있다. 각 이행 서버(16)는 또한 하나 이상의 제품에 대하여 자신이 갖고 있는 공급량(supply)이나 할당량을 지원할 수 있다. 이것은 많은 부가적인 기술적인 장점들을 제공하며, 그 장점들 중 하나는 다양한 클라이언트(12)를 지원하기 위해 조정되고(tailored) 최적화된(optimized) 이행 서버(16) 때문에 분산된 ATP 시스템을 설정할 때(set up) 탄력성이 증가한다는 것이다. 또한, 이러한 옵션들은 공통 제품(common product)들의 요청할 때, 대기 시간을 줄이고 처리율을 증가시키기 위하여 이행 서버(16)에서 제품 공급의 로컬 할당량(local allocation)을 용이하게 설정할 수 있도록 한다.
각 이행 서버(16)는 LFM(22)으로서 동작할 수 있는 능력을 가질 수 있다. 일 실시예에서, 각 이행 서버(16)는 적어도 각각의 LFM(22)을 지원하기에 적절한 ATP 서버(14)일 것이다. 다른 상황에서, 제1 이행 서버(16), 대응하는 LFM(22), 제2 시스템 내의 ATP 서버로서 LFM(22)의 관련 ATP 서버(14)를 포함하는 제1 시스템을 이용하여 LFM(22)의 계층을 형성할 수 있다. 제2 시스템은 제2 이행 서버(16), 대응하는 LFM(22), 이 대응하는 LFM(22)에 관련된 ATP 서버를 포함한다. 이런 방식에서, 적절한 폭(breadth)과 깊이(depth)를 갖는 LFM(22) 및 ATP 서버(14)의 계층은 특별한 필요에 따라서 형성될 수 있다. 본 발명은 하나 이상의 LFM(22)과 하나 이상의 이행 서버(16) 간에 소정의 적당한 관계를 고려한다(contemplate).
이런 계층적인 조직은 많은 부가적인 시스템 설계를 용이하게 하고, 많은 부가적인 기술적인 장점을 제공한다. 예를 들어, 이런 계층 내의 각 LFM(22)은 처리해야 하는 하나 이상의 제품을 할당받을 수 있고, 각 LFM(22)에서 제품은 관련 제품 또는 일반 제품에 대한 계층의 일부이다. 이 경우에, LFM(22)은 일반 제품에 대응하는 특정 LFM(22)으로 전송하여 할당된 제품류(generics of an assigned product)의 가용성을 계산할 수 있으며, 추가적으로 병렬 처리화(parallelization)와 범위성을 제공한다.
또한 미합중국 특허 출원 번호 제08/802,434호에 기술된 이행 서버(16)는 한명 이상의 제품 판매자에 대한 계층을 지원할 수 있고, 각 LFM(22)은 이런 판매자들 중 특별한 한 판매자에 상응할 수 있다. LFM(22)은 자신과 연관된 판매자에 대한 공급 할당량을 유지하고, LFM(22)이 가지고 있는 할당량으로 가능한 모든 부품 견적 및 부품 계약을 계산할 수 있다. 마치 ATP 요청(30)에 의해 모든 할당량을 갖는 단일 시스템으로부터 견적 받거나 이 단일 시스템과 계약을 한 것처럼, 이행 서버(16)는 이러한 부품 견적이나 부품 계약을 받아볼 수 있고, 각 제품에 대하여 이런 견적이나 계약을 결합시킨다. 결과적으로, 시스템(10)은 제품 할당량을 판매자 기준에 따라서 판매자에 대한 LFM(22) 및 관련 ATP 서버(14)로 분산시킬 수 있는 능력을 제공한다. 그러므로 많은 판매자를 갖는 애플리케이션에서 공간 및 시간 범위성 모두를 획득하고, 판매자 조직이 지리적으로나 경제적으로 분리되는 애플리케이션에서 탄력성을 획득한다. 각 LFM(22)은 부 판매자(parent seller)에 대응하는 LFM(22)으로 하나 이상의 부품 ATP 요청(32)을 전송하여 LFM(22)의 부 판매자에 대한 가용성을 계산할 수 있다. 또한, 복수의 LFM(22)은 특정 제품에 대한 개별적인 할당량을 보유할 수 있고, 이행 서버(16)는 적당한 견적을 얻기 위하여필요에 따라 이 LFM(22)을 통하여 견적(quoting activity)을 분산시켜 받아볼 수 있다. 이러한 시스템(1)의 특징이나 다른 시스템(10)의 특징은 판매자 시스템의 분산 배치뿐만 아니라 유리한 병렬 처리화(parallelization), 범위성, 처리율을 제공하거나, 이러한 것들을 제공할 수 있도록 한다.
심지어 더 나아가는 범위성을 제공하기 위하여, 좀더 세분화된 분류(breakdown)를 행할 수도 있다. 일 실시예에서, 제1 이행 서버(16)는 각각 하나 이상의 지정된 제품을 할당받거나 또는 이 하나 이상의 지정된 제품에 대응하는 LFM(22)과 동작할 수 있다. 각 LFM(22)은 개별적인 LFM(22)에 의해 다시(back) 제2 이행 서버(16)인 ATP 서버(14)를 차례로 이용할 수 있다. 이 LFM(22)은 지정된 제품에 대한 전체적인 공급 할당량 일부분을 각각 할당시킨다. 제2 이행 서버(16)는 자신의 LFM(22) 각각에 대해 부과된(placed) 처리 부하를 최소화하고 부하를 조정하도록(balance) 이 LFM(22)과 통신 가능하게 설계될 수 있다. 대안적으로, 다양한 LFM(22)에는 처리해야 하는 총 시간 범위(horizon)를 각각 상이한 시간폭으로 분할한 시간이 부여되므로, 따라서 부품 견적(34)을 분류하고(break down) 준비할 수 있다(stage). 이것은 크기와 처리율에 관한 범위성을 최적화하기 위한 대기 시간을 증가시킬 수 있다.
일 실시예에서, 시스템(10)의 부품들은 제품에 관한 ATP 요청을 생성하고, 관리하며, 이행할 때 "요청-계약-수락(request-promise-accept, RPA)"으로 지칭되는 프로토콜을 이용한다. 일반적으로, RPA 프로토콜에 따라서, 고객은 하나 이상의 제품을 요청하고, 공급자는 고객이 요청하는 요구 사항을 가능하면 충족시키는계약을 제공한다. 공급자로부터 제공된 매매 계약을 검토할 때, 고객은 이 계약을 수락하거나 거절한다. 고객이 계약을 수락할 경우, 일반적으로 고객과 공급자 모두는 계약을 체결하기 위하여 이 수락을 신중히 검토한다(consider). 어떤 상황에서, 고객은 이 매매 계약 때문에 특정 기간 내에 자유롭게 거절하거나 수락할 수 없다. RPA 프로토콜은 I2 TECHNOLOGIES, INC로부터 입수 할 수 있는 RHYTHM supply chain planner(SCP) 엔진의 일부분으로서 분산된 공급망의 자발적인 설계 도메인들(autonomous planning domains)간의 공급 및 수요 요청을 관리하기 위한 기준으로 개발되었다.
도 2 내지 도 5는 일련의 작업흐름을 통한 시스템(10)의 동작을 도시한다. 이러한 작업흐름이나 다른 기술된 작업흐름은 본 발명에 따라 확장된 RPA 프로토콜을 완전히(full) 이용하여 상호 작용하는 시나리오(scenario)를 포함한다. 그러나, 모든 가능한 작업흐름이 상호 작용하는 것은 아니고 이 확장된 RPA 프로토콜을 완전히 이용할 때 모두 결과가 나오는 것은 아니다. 이에 한정되지 않고 단지 하나의 예로서, ATP 요청이 발생할 경우 더 이상 고객의 상호 작용 없이 ATP-소비 계약(ATP-consuming promise)을 생성시키는 전자 데이터 교환(electronic data interchange, EDI) 기반 기술을 이용하여, 대형 회사들은 자신들의 고객 주문 대부분(bulk)을 일반적으로 처리할 수 있다. 이 분야의 당업자는 시스템(10)이 EDI 기반 작업흐름 또는 다른 적당한 작업흐름을 적용시킬 수 있고(accommodate), 본 발명은 이런 모든 작업흐름들과 관련 동작을 포함하기 위한 것이라는 것을 알 수 있을 것이다.
ATP 요청 작업흐름(ATP Request Workflow)
도 2는 ATP 요청 작업흐름을 예시적으로 도시한 것으로, 다수의 품목 ATP 요청(multiple line-item ATP request)(30)이 클라이언트(12)에서 생성되고, 클라이언트(12)가 ATP 요청(30)을 이행 서버(fullfillment server)(16)에 제출하며, 이행 서버(16)는 ATP 요청(30)을 하나 이상의 LFM(22)에 부품 ATP 요청(32)의 형태로 중개한다. 이 LFM(22)는 부품 ATP 요청(32)을 연관된 ATP 서버(14)와 협력하여 처리하고, 부품 견적(34)을 결과로서 생성하며, 생성된 부품 견적(34)을 이행 서버(16)로 전송한다. 이행 서버(16)는 부품 견적(34)을 처리하여 통합 견적(unfied quotation)(36)을 생성하고, 이것은 검토를 위하여 클라이언트(12)로 전송된다.
ATP 요청 개시(Initiate ATP Request)[클라이언트]
일 실시예에서, ATP 요청(30)을 개시하기 위하여 클라이언트(12) 또는 연관된 사용자는 적절한 식별 및 보안 정보(identification and security information)을 제공하는 것이 요구될 수 있다. 클라이언트(12)는 디폴트 거래 규칙(default business rules)이나 사용자 프로파일(profile), 고객 프로파일 또는 다른 적당한 한정(definitions)에 따르는 다른 제약조건을 지원할 수 있다. 사용자가 클라이언트(12)와 연관된 ATP 요청 스크린(screen)에 접속하는 경우, 이 스크린은 그러한 한정에 따르는 디폴트 파라메터(default parameters)와 함께 존재할 수 있다(populated). 그런 다음, 사용자는 특정 ATP 요청(30)의 요구에 적합하도록 임의로 이러한 파라메터의 일부 또는 모두를 조정할 수 있다. 이러한 파라메터는선적 요구조건(shipping requirements), 제품 소싱(product sourcing)에 관한 선택물(preferences), 제품의 대체물(product alternates)이나 대용물(substitutions) 및 선적 위치(ship-to location), 가격 목표(price targets) 그리고 다른 임의의 적당한파라메터들을 포함할 수 있다. 사용자는 제품을 제품 카탈로그(product catalog), 검색 엔진(search engine) 등을 사용하여 제품 그룹이나 다른 적당한 방식에 따라 조직된 입수 가능한 제품들에 대한 표(table)에서 선택할 수 있다. 일단 사용자가 하나 이상의 제품을 선택하면, 사용자는 원하는 수량(quantities), 원하는 기일(due date) 및 앞서 설명한 것과 같은 소정의 추가적인 파라메터들을 지정할 수 있다. 사용자는 또한 선적 스케줄링을 목적으로 요청 품목(request ine-items)을 그룹핑할 수 있다. 클라이언트(12)는 ATP 요청(30)이 완전하게 명기된 경우에 ATP 요청 제출 기능(ATP request submission function)을 실행하여, ATP 요청(30)을 이행 서버(16)로 전송한다.
비록 소정의 적당한 데이터나 메시지 구조가 본 발명이 의도하는 기술적 범위를 벗어나지 않고 사용될 수 있기는 하지만, ATP 요청(30)은 요청 객체, 요청 품목 객체 및 요청 품목 인도 객체(request line-item delivery object)를 포함하는 3레벨의 부자 계층(three-level parent-child hieracy)으로 구성될 수 있다. 예로서, ATP 요청(30)에 대한 대체(altenative) 3레벨 구조는, 각각 하나 이상의 요청 품목 객체들을 포함하는 하나 이상의 요청 인도 객체들의 목록을 포함하는 요청 객체를 포함해도 된다.
요청 속성(Request Attributes)
일 실시예서, 요청 객체는 임의의 적당한조합으로 다음의 속성을 갖거나 다음의 정보를 지원하며, 이에 한정되지 않는다: (1) 사용자 ID- 요청을 제출하는 클라이언트(12)의 사용자; (2) 고객 ID- 요청에 대한 거래 제약조건을 결정하기 위해 사용됨; (3) 고객 요청 ID- 클라이언트(12)에서 할당되고, 고객의 의도(purpose)를 추적하기 위해 주로 사용됨; (4) 요청 ID- 이행 서버(16)에서 할당되고, 계속하는 프로세싱(processing)과 관리 활동(administrative activities)을 위해 사용됨; (5) 통화(currenccy)- 요청에서 선택된(preferred) 통화이고, 어쩌면 작성된 거래 제약조건(profiled business constraints)에서 디폴트로 지정됨; (6) 판매 채널(sales channel)(판매자)- 요청에 대한 판매 채널이며, 복수 레벨의 채널 계층(multi-level hierarchy)에 기초한 할당 기능성(allocation functionality)을 제공하는 ATP 서버(14)와 ATP를 소비하는 것으로부터 채널을 결정하는 판매자에게서 유용함; (7) 요청 순위(request rank)- 수(numeric) 또는 동일한 제품에 대한 다른 요청들에 관련한 요청 순위이며, 공급 문제(supply problems)의 견지에서 부족한 공급량(supply)을 할당하는 경우와 같은 주문 스케줄링 프로세스(order scheduling process) 내의 요청들의 순위 차(differential ranking)에 비례하여 기능성을 제공하는 ATP 서버(14)에서 정렬 기준(sort criterion)으로서 유용함; (8) 선적(ship-to)- 요청에 대한 선적 위치이고, 이것은 각 요청 품목에 대해 디폴트로 지정할 수 있음; (9) 지정변경 고객 제약조건(override customer constraints)- LFM(22)으로부터의 응답이 제약을 받지 않도록 사용자에게 이행 서버(16)의 거래 제약조건 프로세싱 기능성에 대한 지정변경을 허용함; (10) 전체 가격 목표(totalprice target)- 요청에 대한 사용자 명기(user-specified) 전체 가격 목표이고, 이것은 이행 서버(16)가 LFM(22)으로부터의 응답 평가에 고려할 수 있으며, 충족되지 못하는 경우에 견적 결과를 나타낼 수 있음; (11) 대체물/대용물 허용(alternates/subsitutes allowed)- 작성된 거래 제약조건에서 디폴트로 지정된 논리(예/아니오) 파라메터이고, 이것은 사용자가 선택적으로 지정을 변경할 수 있으며 이행 서버(16)가 요청 처리에 사용할 수 있음; (12) 수락 가능한 대체 위치(alternate location acceptable)- 작성된 거래 제약조건에서 디폴트로 지정된 논리 파라메터이고, 이것은 사용자가 선택적으로 지정을 변경할 수 있으며 이행 서버(16)가 요청 처리에 사용할 수 있음 ; (13) 선적 완료(ship complete)- 작성된 거래 제약조건에서 디폴트로 지정된 논리 파라메터이고, 이것은 사용자가 선택적으로 지정을 변경할 수 있으며, 이행 서버(16)가 요청 수량(request quantity) 속성이 충족되지 못하는 부품 견적들이 거절되도록 요청 처리에서 사용할 수 있음; (14) 불완전/취소(partial/cancel)- 작성된 거래 제약조건에서 디폴트로 지정된 논리 파라메터이고, 이것은 사용자가 선택적으로 지정을 변경할 수 있으며 이행 서버(16)가 늦은 계약(late promises)(요청 중에서 이행되지 않은 부분)이 포기되거나(dropped) 주문 잔고(order backlog)로서 가지고 있도록 요청 처리에서 사용할 수 있음; (15) 정시 선적(ship on-time)- 작성된 거래 제약조건에서 디폴트로 지정된 논리 파라메터이고, 이것은 사용자가 선택적으로 지정을 변경할 수 있으며 이행 서버(16)가 LFM(22)으로부터의 이르거나 늦은(early or late) 부품 계약(component promises)을 받아들일 수 있는가에 따라 요청 처리에서 사용할 수 있음; (16) 부족비율(short proportional)- 작성된 거래 제약조건에서 디폴트로 지정된 논리 파라메터이고, 이것은 사용자가 선택적으로 지정을 변경할 수 있으며 이행 서버(16)가 논리적으로 연관된 요청 품목 사이의 계약이 다른 부족한 요청 품목에 비례하여 감소(부족)되도록 요청 처리에서 사용할 수 있음; (17) 최초 요청일(initial date requested)- 견적을 위해 요청이 이행 서버(16)에 제출된 최초의 날짜; (18) 최후 요청일(last date requested) - 재견적(re-quotation)을 위해 이행 서버(16)에 제출된 요청이 있다면 그 최후의 날짜; (19) 견적일(date quoted)- 만약 있다면, 요청이 최후로 견적을 받은 날짜; (20) 수락일(date accepted)- 만약 있다면, 클라이언트(12)가 최후로 요청을 수락한 날짜; (21) 거절일(date rejected)- 만약 있다면, 클라이언트(12)가 최후로 요청을 전부 거절한 날짜; (22) 계약일(date promised)- 만약 있다면, 최후로 요청이 계약된 날짜; (23) 취소일(date cancled)- 만약 있다면, 요청이 취소된 날짜; 및 큐잉일(queuing date)- 만약 있다면, 요청이 최후로 큐에 저장된 날짜.
또한, 이 요청 객체는 ATP 요청(30)의 수명 동안에 소정의 이정표(milestones)에서 이행 서버(16)가 갱신하는 요청 상태 필드(request status field)를 지원할 수 있으며, 갱신 정보는 다음을 포함하지만 이것으로 한정되지는 않는다: (1) "요청 실패(failed request)" - 최초 견적 또는 재견적을 위해 제출된 요청이지만 하나 이상의 요청 품목이 요구조건을 충족시키지 못하는 요청; (2) "견적중(pending quotation)"- 최초 견적 또는 재견적을 위해 제출된 요청이지만 아직까지 견적 결과가 처리되지 않은 요청; (3) "견적 실패(failed quotation)"- 이행서버(16)가 요청에 대해 작성된 거래 제약조건을 충족시키는 것에 실패한 것으로 결정한 견적; (4) "수락중(pending acceptance)"- 이행 서버(16)가 견적을 처리하여 그것을 클라이언트(12)에 전송하였지만 아직까지 응답하지 않음; (5) "수락 미수신(acceptance not received)- 수락 기한(accept-by) 속성에 명기된 날짜 및 시간까지 클라이언트(12)로부터 견적에 대한 확인(quotation confirmation)이 수신되지 않아, 견적을 반드시 널 값(null)으로 하여 무효(void)로 함; (6) "거절(rejected)- 이행 서버(16)가 거절을 처리하여 그것을 LFM(22)에 전송; (7) "계약 체결중(pending promise)"- 이행 서버(16)가 견적 확인을 처리하여 그것을 LFM(22)에 전송하고, LFM(22)으로부터의 부품 계약 응답을 현재 감시중 임; (8) "계약"- 이행 서버(16)가 부품 계약을 수신하여 클라이언트(12)에 계약 결과를 전송함; (9) "계약 실패(failed promise)"- 이행 서버(16)가 아직 LFM(22)으로부터 부품 계약을 수신하지 못하여 클라이언트(12)에게 실패 통지(notification)를 전송하였음; (10) "취소중(pending cancellation)"- 이행 서버(16)가 취소 처리를 하여 그것을 LFM(22)에 전송하고, LFM(22)으로부터의 확인 응답을 감시중임; (11) "취소(canceled)"- 이행 서버(16)가 LFM(22)으로부터 필요한 취소 확인을 수신하여, 그 확인을 클라이언트(12) 전송하였음; 및 (12) "큐잉(queued)"- 이행 서버(16)가 큐 명령에 대한 요청을 처리하고, 재견적에 대한 요청을 감시중임.
요청 품목 속성(Request Line-Item Attributes)
일 실시예에서, 요청 품목은 임의의 적당한조합으로 다음의 속성을 갖거나 다음의 정보를 지원하는 객체이며, 이에 한정되지는 않는다: (1) 요청 ID- 요청 품목을 요청에 연결함(link); (2) 요청 품목 ID- 이행 서버(16)에서 할당됨; (3) 선적(ship-to)- 요청 품목에 대한 디폴트 선적 주소(ship-to address)이고, 이것은 요청으로부터 디폴트로 지정되며 사용자가 선택적으로 지정을 변경할 수 있고, 인도 품목 요청(line-item delivery request)에 대해 디폴트로 지정됨; (4) 수락 기한- 사용자가 견적을 수락해야 하는 날짜 및 시간; (5) 계약 기한(promise-by)- 이행 서버(16)가 계약으로 응답해야 하는 날짜 및 시간; (6) 제품 ID- 품목을 요청할 때에 요청된 제품; (7) 제품 UOM- 요청된 제품에 대한 주요 치수 단위; (8) 요청 수량(request quantity)- 요청된 제품의 수량이나 수량 범위이고, 이것은 다수의 요청 품목 인도가 정의된 경우에 결합되는 인도 수량과 동일해야 함; (9) 요청일(request date)- 제품이 고객이 원하는 선적 위치에 도착하도록 요구받은 날짜 및 날짜 범위이고, 요청 품목에 대해 다수의 요청 품목 인도가 존재하는 경우에 사용자가 지정을 변경할 수 있음; (10) 카테고리/속성(category/attribute)- 요청된 제품에 대한 카테고리/속성의 조합(combinations); (11) 품목 그룹핑(line-item grouping)- 인도 조정(delivery coordination)을 위하여 논리적인 그룹핑을 할 때 다수의 요청 품목 사이의 관계를 나타내며, 여기서 그룹핑은 배치(configuration), 제품의 포장단위(bundled package), 함께 선적해야할 품목(items)의 집합, 또는 다른 적당한 그룹핑임; (12) 품목 가격 목표(line-item price target)- 요청 품목에 대한 사용자 명기 목표 가격이고, 이것은 이행 서버가 ATP 서버의 응답들을 평가하는 경우 고려할 수 있으며, 충족되지 않는 경우에 견적 견적을 나타낼 수 있음; (13) 선택된 제품/공급자(preferred product/supplier)-작성된 거래 제약조건에서 디폴트로 지정되고, 이것은 사용자가 선택적으로 지정을 변경할 수 있으며 이행 서버(16)가 요청 품목을 소싱(sourcing)하는 경우 사용함; (14) 대체물/대용물 허용- 작성된 거래 제약조건으로부터 디폴트로 지정되고, 이것은 사용자가 선택적으로 지정을 변경할 수 있으며 이행 서버(16)가 요청 품목을 처리하기 위하여 사용함; (15) 선택된 대체물/대용물- 작성된 거래 제약조건에서 디폴트로 지정되고, 이것은 사용자가 선택적으로 지정을 변경할 수 있으며 이행 서버(16)와 공급자가 요청된 제품에 대해 가능한 대체물 또는 대용물을 선택함에 있어 협력할 수 있도록 함; (16) 필수(mandatory)- 요청 품목이 자신의 그룹내의 다른 것과 관련하여 필수적이든 아니든, 필수 품목의 수량 부족은 견적 실패의 결과를 초래할 수 있음; (17) 로트 크기/배수(lot size/multiple)- 제품의 기본 규정에서 디폴트로 지정되며, 이것은 사용자가 선택적으로 지정 변경을 할 수 있으며 이행 서버(16)가 ATP 서버 응답 수량(response quantities)이 적절히 우수리가 없도록(rounded) 요청 품목의 처리에 사용할 수 있음; (18) 선적 완료(ship complete)- 작성된 거래 제약조건에서 디폴트로 지정되고, 이것은 사용자가 선택적으로 지정을 변경할 수 있으며 이행 서버(16)가 요청 품목의 처리에 사용할 수 있음; (19) 불완전/취소(partial/cancel)- 작성된 거래 제약조건에서 디폴트로 지정되며, 이것은 사용자가 선택적으로 지정을 변경할 수 있고 이행 서버(16)가 요청 품목의 처리에 사용하여 불완전하게 이행되는 경우에 포기될(dropped) 수 있도록 함; (20) 정시 선적- 작성된 거래 제약조건에서 디폴트로 지정되며, 이것은 사용자가 선택적으로 지정을 변경할 수 있고 이행 서버(16)가 요청 품목의 처리에 사용하여 이르거나 늦은 계약을 거절할 수 있도록 함; (21) LFM 응답 상태(LFM response status)- 이행 서버(16)가 부품 ATP 요청을 LFM(22)에 중개한 후에 감시하여, 모든 부품 견적이 수신되었을 경우에 이행 서버(16)가 견적 평가를 시작할 수 있도록 함; (22) LFM 개시 사건 상태(LFM-initiated event staus)- 이행 서버(16)에서 유지되며, 설계 사건(planning event)이 공급에 영향을 미치는 경우에 LFM(22)이 이를 기록하고 이행 서버(16)에 알려서, 이행 서버(16)가 작성된 거래 제약조건들과 관련한 요청의 상태를 재평가하고 요청 상태의 모든 변화를 사용자에게 통지(notify)할 수 있도록 함; 및 (23) 요청 품목 상태(requst line-item status)- 요청 품목의 라이프 사이클(life cycle ) 동안에 소정의 이정표들에서 갱신됨.
요청 품목 인도 속성(Requst Line-item Delivery Attributes)
일 실시예에서, 요청 품목 인도는 임의의 적당한조합으로 이하의 속성을 갖거나 이하의 정보를 지원하는 객체이며, 이에 한정되지 않는다: (1) 요청 품목 ID- 요청 품목 인도를 요청 품목에 연결함; (2) 요청 품목 인도 ID- 이행 서버(16)에서 할당됨; (3) 선적(ship-to)- 요청 품목 인도에 대한 디폴트 선적 주소(default address)이며, 이것은 요청 품목에서 디폴트로 지정되고 사용자가 선택적으로 지정을 변경할 수 있음; (4) 요청 수량- 요청된 제품의 수량이나 수량 범위이고, 요청 품목의 요청 수량과 동일해야 함; (5) 요청일- 요청 품목 인도에 대해 고객이 원하는 선적 위치에 도착하도록 요구받은 날짜 및 날짜 범위이고, 이것은 요청 품목에 대해 다수의 요청 품목 인도가 존재하는 경우에 사용자가 지정을 변경할 수 있음; 및 (6) 카테고리/속성- 요청 품목 인도에 대한 카테고리/속성의 조합이며, 이것은 소정의 요청 품목에 대해 다수의 요청 품목 인도가 존재하는 경우에 사용자가 선택적으로 지정을 변경할 수 있음.
ATP 요청 프로세스(Process ATP Request)[이행 서버]
ATP 요청(30)과 연관된 각각의 품목들은 논리적으로 또는 지리적으로 별개인 ATP 서버(14)에서 이행될 수 있다. 이 작업흐름에서, 이행 서버(16)의 주요 태스크(primary tasks)는 ATP 요청(30)을 개별적인 요청 품목으로 분해하고, 부품 ATP 요청(32)의 결과를 네트워크(20) 및 LFM(22)를 이용하여 ATP 서버(14)의 분산 네트워크에 중개하며, LFM(22)으로부터 수신한 부품 견적(34)을 평가하고, 네트워크(18)를 이용하여 클라이언트(12)로 통합된 견적(unified quotation)(36)을 전송한다. 다수의 인도가 소정의 요청 품목에 대해 명기되었으면, 이행 서버(16)는 각각의 인도에 대해 개별적인 부품 ATP 요청(32)을 생성한다. 일부 또는 전체 부품 ATP 요청(32)은 고객의 거래 제약조건, 사용자의 선택(preference) 또는 공급자가 선택한(supplier-prefferred) 소싱 규칙(sourcing rules)에 따라 특정 LFM(22)에서 사전 소싱(pre-sourced)될 수 있다. 이에 대한 대안으로, 다수의 LFM(22)이 견적에 대한 응답을 제공하는 기회를 가지도록 소싱 선택은 지정되지 않을 수 있다. 일 실시예에서, 이행 서버(16)는 고객 및 다른 적당한 거래 제약조건을 LFM(22)으로 전송하기 전에 부품 ATP 요청(32)으로 분해하고(decompose) 요약한다(encapsulate).
각 제품에 대해, 공급자는 최소 및 최대 주문량(order quantity)에 요구조건을 명기할 수 있다. 일 실시예에서, 이러한 요구조건의 파라메터들이 명기되었으면, 이행 서버(16)는 각각의 요청 품목이 그러한 요구조건을 충족시키는지를 처음부터 평가한다. 만약 어떤 요청 품목이 명기된 요구조건들을 충족시키지 못하는 경우, 실패 응답(failure response)이 생성되고 이는 네트워크(18)를 이용하여 요청한 클라이언트(12)에 전송된다. 이 경우에, 이행 서버(16)는 어쩌면 실패한 부품 ATP 요청(32)을 "요청 실패(failed request)"로 ATP 요청(30)의 상태를 갱신한다.
이행 서버(16)는 공급자 또는 위치에 따라 각각의 요청 품목에 대해 소싱을 규정하는 것을 시도할 수 있다. 그런 다음 이행 서버(16)는 명확하게 특정 LFM(22)에 대해 부품 ATP 요청(32)을 목표로 삼을 수 있다. 사용자가 작성된 디폴트 제약조건을 무효화 시켰을 수도 있기 때문에, 이행 서버(16)는 먼저 요청 품목과 요청 품목 인도 명세(details)를 평가한 다음, 대체물이 ATP 요청(32)에 대해 허용된 것이지를 결정하기 위하여 대체 공급자(alternat supplier)와 위치 소싱 속성을 확인한다. 만약 대체물이 허용되지 않으면, ATP 요청(30)에 명기된 주요 관계(primary relationship)가 받아들여 질 것이다. 만약 대체 소싱(alternate sourcing)이 허용되면 사용자, 고객 또는 다른 대체 소싱 선택(sourcing preference)이 우선된다. 만약 이러한 소싱 선택이 명기되지 않았다면, 이행 서버(16)는 모든 공급자의 디폴트 선택의 존재를 확인할 수 있다. 만약 공급자에 대한 명기된 선택이 없으면, 부품 ATP 요청(32)은 목표 LFM(target LFM)(22)과 관련하여 "명기 않됨(unspecified)"으로 표시될 수 있다. 이 경우에, 다수의 LFM(22)은 적절히 부품 ATP 요청(32)에 대해 서비스하고 응답하는 것이 허용될 수있다.
이행 서버(16)는 ATP 요청(30)에 대한 대체 또는 대용 선택물의 규정을 시도할 수 있다. 이행 서버(16)는 부품 ATP 요청(32)에 있어 대체 제품의 정보를 포함할 수 있다. 사용자가 작성된 디폴트 제약조건을 선택적으로 지정을 변경하였을 수 있으므로, 이행 서버(16)는 먼저 요청 품목과 요청 품목 인도 명세(details)를 평가한 다음, 대체물 또는 대용물이 허용되는지를 결정하기 위하여 ATP요청(30)을 확인한다. 만약 허용되지 않으면, ATP 요청(30)에 명기된 주요 관계가 받아들여진다. 만약 대체 또는 대용 제품이 허용되면 사용자, 고객 또는 다른 적당한 대체나 대용 선택물이 우선된다. 만약 이러한 선택물이 지정되지 않았다면, 이행 서버(16)는 모든 공급자의 디폴트 대체물을 확인할 수 있다. 만약 공급자에 대해 명기된 선택물이 존재하지 않으면, 부품 ATP 요청(32)은 대체물 및 대용물과 관련하여 "명기 않됨"으로 표시될 수 있다. 이 경우에, LFM(22)은 다수의 제품 옵션과 함께 부품 ATP 요청(32)에 대해 응답할 수 있다.
이행 서버(16)는 거래 제약조건을 포함하는(embedded) 부품 ATP 요청(32)을 생성한다. 사용자가 작성된 디폴트 제약조건을 상호 작용으로 무효화(overriden) 시켰을 수도 있기 때문에, 이행 서버(16)는 부품 ATP 요청(32)의 속성들을 규정하기 위하여 요청 품목 및 요청 품목 인도 명세를 사용한다. 일 실시예에서, 임의의 적당한조합으로, 요청 수량, 선적 완료, 불완전/취소, 정시 선석, 대체물/대용물 허용, 선택된 대체물/대용물(preferred alternates/substitues), 로트 크기/배수(multiple) 및 소비 전방/후방 한계(consume forward/backwardboundaries) 등의 제약조건이 규정되며, 이에 한정되지 않는다. 또한 이행 서버(16)는 작성된 거래 제약조건에 따라 특정한 방식으로 추가로 제한된 부품 ATP 요청(32)을 나타낼 수있다. 일단 부품 ATP 요청(32)이 생성되었으면, 이행서버(16)는 네트워크(18)를 이용하여 이 부품 ATP 요청(32)을 처리하기 위하여 하나 이상의 LFM(22)으로 전송한다. 또한 이행 서버(16)는 ATP 요청(30)의 상태를 갱신할 수 있으며, 어쩌면 부품 ATP 요청(32)을 "견적중"으로 갱신할 수 있다.
일 실시예에서, 이행 서버(16)는 부품 ATP 요청(32)의 시퀀스를 계산하거나 생성하여, 시퀀스 중에서 최초의 부품 ATP 요청(32)에 연관된 특정 LFM(22)으로 전송한다. 목표 LFM(22)은 이 시퀀스를 받아, 명확하게 자신을 목표로 삼은 부품 ATP 요청(32)을 처리한 다음, 시퀀스에서의 나머지 부품 ATP 요청(32)과 함께 부품 견적 또는 부품 계약의 결과를 다음 부품 ATP 요청(32)에 의해 목표가 되는 LFM(22)으로 전달한다. 차례로, 해당 LFM(22)은 시퀀스를 받아 명확하게 자신을 목표로 삼은 부품 ATP 요청(32)을 처리하여, 시퀀스에서의 나머지 부품 ATP 요청(32)과 함께 부품 견적이나 부품 계약의 결과를 다음 부품 ATP 요청(32)에 의해 목표가 되는 LFM(22)으로 전달한다. 이러한 각각의 LFM(22)은, 시퀀스에서 더 앞선 다른 LFM(22)에 의해 이루어진 부품 견적 또는 부품 계약에 관련한 모든 적당한 거래 제약조건들을 충족시키도록 자신의 부품 견적 또는 부품 계약을 계산할 수 있다. 이행 서버(16)는 이러한 마지막 LFM(22)으로부터 부품 견적 또는 부품 계약 결과의 시퀀스를 수신하고, 클라이언트(12)로부터의 ATP 요청(20)에 부합하는 결합된 견적 또는 계약을 생성한다.
부품 ATP 요청 속성(Component ATP Request Attributes)
일 실시예에서, 부품 ATP 요청(32)은 요청 품목 및 요청 품목 인도 객체들의 일부 또는 모든 속성을 갖는 객체이다. 이행 서버(16)는 LFM(22)의 기능(functions)에 관계가 있는 부품 요청에 거래 제약조건을 포함한다. 이행 서버(16)는 임의의 적당한조합으로 이하의 속성을 갖거나 이하의 정보를 지원할 수 있으며 이에 한정되지 않는다: (1) 부품 요청 ID- 이행 서버(16)가 부품 요청을 생성하는 경우에 이행 서버(16)에서 할당됨; (2) LFM ID- 부품 요청의 목표 LFM(22)이고, 이것은 소싱 관계(sourcing relationsip)가 명기되지 않거나 생성되지 않은 이행 서버(16)에서 명기되지 않은 채로 남을 수 있고, 이 경우에 요구조건들을 충족시킬 수 있다면 모든 LFM(22)은 부품 요청에 대한 응답이 자유롭다; (3) 이행 서버 ID- 이행서버(16)에 대한 네트워크 주소 또는 다른 식별자이며, 이것은 다수의 이행 서버(16)를 구비하는 환경에서 유용함; (4) 부품 요청에 대한 판매 채널(판매자); (5) 부 요청(parent request)에 대한 요청 순위; (6) 요청 품목 ID- 부품 요청을 요청 품목에 연결함; (7) 요청 품목 인도 ID; (8) 제품 ID- 하나 이상의 목표 LFM(22)에 대해 알려진 제품 ID에 대응할 수 있고, 어쩌면(possibly) ATP 서버(14)에 대응할 수도 있음; (9) 제품 UOM- 하나 이상의 목표 LFM(22)에서 사용되는 제품 UOM에 대응할 수 있고, 어쩌면 ATP 서버에 대응할 수도 있음; (10) 요청 수량; (11) 요청일; (12) 카테고리/속성; (13) 선적 완료; (14) 불완전/취소; (15) 정시 선적; (16) 로트 크기/배수; (17) 대체물/대용물 허용; (18) 선택된 대체물/대용물; 및 (19) 소비 전방/후방 한계- 요청일로부터 전후로 얼마나 멀리 ATP 서버(14)가 입수 가능한 수량을 검색할 것인가를 제어할 수 있는, 고객이 기꺼이 수락하는 인도 범위(delivery window)를 규정함.
또한, 부품 요청 객체는 부품 요청의 라이프 사이클 동안에 이행 서버(16)가 소정의 이정표에서 갱신하는 다음의 것을 포함하지만 이것으로 한정되지는 않는 요청 상태 필드를 지원할 수 있다: (1) "견적중"- 초기 견적 또는 재견적을 위해 제출된 부품 요청이지만, 견적 결과가 처리되지 않음; (2) "견적 실패"- 이행 서버(16)가 부품 요청에 대한 요구조건을 충족시키는 것에 실패한 것으로 결정한 부품 견적; (3) "견적중 확인(pending quotation confirmation)"- 이행 서버(16)가 견적을 처리하고 그것을 클라이언트(12)에 전송하였으나 아직 응답을 받지 못함; (4) "확인 미수신(confirmation not received)"- 수락 기한(accept-by)으로 지정한 날짜 및 시간까지 클라이언트(12)로부터 확인이 수신되지 않음; (5) "거절"- 이행서버(16)가 거절을 처리하고 그것을 LFM(22)에 전송하였음; (6) "계약 체결중(pending promise)"- 이행 서버(16)가 계약 확인을 처리하고 그것을 부품 확인(component confirmations)으로서 LFM(22)에 전송하였고, 이행 서버(16)가 계약 응답을 감시중임; (7) "계약(promised)"- 이행 서버(16)가 부품 계약의 요구조건을 수신하였고 그것을 클라이언(12)에 전송함; (8) "계약 실패"- 이행 서버(16)가 부품 계약의 요구조건을 수신하지 못하였고, 실패 결과 통지를 클라이언트(12)에게 전송하였음; (9) "취소중"- 이행 서버(16)가 취소를 처리하였으며, 그것을 LFM(22)에 전송하였고, 확인 응답을 감시중임; (10) "취소"- 이행 서버(16)가 LFM(22)으로부터 부품 취소 확인을 수신하였고, 클라이언트(12)로 취소 확인을 전송하였음.
부품 ATP 요청 프로세스(Process Component ATP Requests)[LFM]
이행 서버(16)로부터의 부품 ATP 요청(32)은 각각 적당한 LFM(22)에서 수신된다. 위에서 설명한 바와 같이, LFM(22)은 일반적으로 부품 ATP 요청(32)을 관리하고 ATP 요청(30)이 생존하는 동안 이행 서버(16)와 연관된 ATP 서버(16) 사이에 통신하기 위하여 응답할 수 있다. 일 실시예에서, LFM(22)은 연관된 ATP 서버(14)에 대한 견적, 계약, 수락, 선적 및 보관 작업(archive operations)을 포함할 수 있다. 만약 명기된 소싱 선택이 있으면, 부품 ATP 요청(32)은 그 정보를 포함할 수 있으며, 적절히 LFM(22)이 부품 ATP 요청(32)을 식별하고 처리할 수 있도록 한다. 만약 명기된 소싱 선택이 없으면, LFM(22)은 사용자, 고객 또는 제품에 기초하여 부품 ATP 요청(32)에 관련된 식별이 가능하다. 특정 ATP 서버 위치에서, LFM(22)는 부품 ATP 요청(32)을 수신하고 특정 연관된 설계 엔진에 적합한 명령 구문(command syntax)을 이용하여 ATP 서버(14)로 견적 요청을 발생시킨다. 이 프로세싱의 일부로서, LFM(22)은 부품 ATP 요청(32)에 포함된 거래 제약조건들을 평가하고 그에 따라 행동한다.
설계 엔진은 이러한 인터페이스의 제약조건에 관련하여 변화할 수 있다. 일례로서, FP 엔진은 할당된 제품 가용성(product availability)을 소비할 요청 트랜잭션(request transactions)에서의 ATP를 유지하지 않는다. 각 부품 요청은 완성품 재고(finished goods inventory), 입수 가능한 자재(available materials) 및 제품 가용성을 결정하는 다른 적당한 인자(factors)의 설명(representation)을 배경으로 설계된다. 선적 타이밍(shipment timing) 및 로트 크기 결정(lot sizing)의 관점에서는 견적 결과에 대한 응답의 출력 구조를 제어하는 기능성(functionality)이 거의 없을 수 있다. 이러한 상태에서, LFM(22)은 설계 트랜잭션으로서 견적 요청을 제출할 수 있고, 부품 ATP 요청(32)에 포함된 거래 제약조건에 따라 견적 응답을 평가한다. ATP 서버(14)로부터의 응답이 이러한 요구조건들을 충족시키지 못하면, LFM(22)은 이를 확인하여 이행 서버(16)에 실패 통지를 전송한다.
예를 들어, 부품 ATP 요청(32)에서의 선적 완료 속성이 요청이 전부 충족되는 것을 요구하고, ATP 서버(14)로부터의 견적 응답이 요청 수량 속성보다 적으면, LFM(22)은 부품 견적(34)을 실패한 것으로 나타낼 수 있고, 실패에 대해 적절하게 설명한 주석(annotation)을 제공할 수 있다. 이러한 최전선의 평가(front-line evaluation)는 설계 엔진에 따라서는 중요할 수 있기 때문에, ATP 서버의 응답은 다차원(multi-demensional)일 수 있다(다수의 옵션 제공). 이행 서버 레벨에서보다 LFM 레벨에서 응답 평가를 제공하는 것은, 부품 견적(34)이 이행 서버(16)로 반환되기 전에 실패 조건(failure conditions)이 확인되고 요약될 수 있도록 한다.
다차원 ATP 서버 응답의 일례로서, 소정의 요청 품목(예: 바퀴(weel) 100개, 5월 8일)을 생각하면, 그 응답은 바퀴 60개는 5월 8일에 $22에, 및/또는 바퀴 30개는 5월 10일에 $16에, 및/또는 바퀴 100개는 5월 12일에 $16에 입수 가능하다는 것일 수 있다. 이것은 품목 견적에 대한 다수의 옵션이다. 시스템(10)은 규칙과 범위들을 통합할 수 있다. 예를 들어, 5월 12일에 $16 라는 옵션이 이것과 일치하지 않는 수량 제한(quantity restriction)을 포함하는 것이라면, 5월 10일에 바퀴 30개를 그리고 5월 12일에 나머지 바퀴 70개를 입수할 수 있는 가능성(ability)은 제약받을 수 있다.
추가적인 예로서, 3개의 요청 품목(예: 바퀴 100개, 단순한 차축(simple axle) 25개 및 복합 차축(complex axle) 25개를 5월 8일에 비례적으로(proportionally) 인도)을 생각하자. 개별 품목 견적은 위에서와 같이 다수의 옵션을 갖고서 계산될 수 있으며, 그런 다음 어떤 적당한 방식으로 결합된다. 예를 들어, 단순 차축은 5월 9일에 15개, 그리고 5월 11에 25개를 $10에 입수 가능할 수 있다. 복합 차축은 5월 8일에 10개 그리고 5월 10일에 25개를 $25에 입수 가능할 수 있다. 요청에 포함된 비례성(proportionality) 거래 제약조건을 무시하면, 주문을 충족시키는 제품의 인도는 몇일지나 5월 8일에서 5월 12일 사이에서 적절히 일어날 수 있다. 그러나 비례성 거래 제약조건은 품목들이 얼마나 요청되었는가에 비례하는 양으로 인도되어야만 하는 지시일 수 있기 때문에, 예를 들어 차축이 인도되지 않는 경우에 바퀴가 인도되는 것이 소용없는 것일 수 있다. 상기한 것은 다수 품목에 대한 견적을 포함하고 예시한 비례성 거래 제약조건을 따르는 다음에 예시한 다차원 견적을 초래할 수 있다:
5월 9일- 바퀴 40개, 각각의 차축 10개, $(22*40+10*10+25*10)
5월 10일- 바퀴 28개, 각각의 차축 7개, $(16*28+10*7+25*7)
5월 10일- 바퀴 60개, 각각의 차축 15개, $(16*30+22*30+10*15+25*15)
5월 11일- 바퀴 88개, 각각의 차축 22개, $(16*30+22*58+10*22+25*22)
5월 12일- 바퀴 100개, 각각의 차축 25개, $(16*100+10*25+25*25)
일 실시예에서, 시스템(10)은 많은 다른 거래 제약조건을 지원하고, 거래 제약조건 중 일부는 명기되기 위한 하나 이상의 여분의 필드(extra fields)를 필요로 할 수 있다. 이것을 모델링하는 것은, 본 명세서에 모두 참조되어, 본 명세서의 일부를 이루는 미합중국 특허 제5,764,543호 및 제5,930,156호에 기재된 바와 같이, 거래 제약조건 필드(field)는 확장 선택기(extension selector)일 수 있다. 추가적인 확장 필드는 대응하는 확장값이 확장 선택기 필드에 삽입되는 경우에 실시될 수 있다. 제한을 위한 것이 아니라 단지 예로서, 최대 변화 제약조건(maximun variance constraint)은 ATP 요청(30)에 대해서 명기될 수 있으며, 추가적인 필드는 최대_변화_퍼센트(max_vaiance_percentage)라고 하는 요청 모델(request model)에 부가되어, 클라언트(12) 또는 연관된 사용자에게 요청된 수량에서 허용되는(tolerated) 변화량을 명기하도록 한다. 이 필드는 존재하지 않을 수 있으며, 최대 변화 제약조건이 명기되지 않는 경우에 어떤 메모리 공간도 차지하지 않을 수 있다. 시스템(10)은 여기에서 설명한 임의의 또는 모든 거래 제약조건과 관련하여 사용되는 확장 가능한 모델 또는 용량(capability)을 허용할 수 있으며, 상당한 유연성(flexibility) 및 플랫(flat) 또는 다른 이전의 모델링 기술을 능가하는 중요한 기술적 이점을 제공한다.
시스템(10) 내에서, 여러 LFM(22)은 예를 들어, 상세한 공급 가용성을 포함하지 않는 다양한 불완전(partial) 견적 또는 불완전 계약을 계산할 수 있다. 이런 일이 발생하는 경우, 이행 서버(16)는 불완전한 견적 정보를 이용하여 결합된 계약을 생성시키도록 태스킹 될 수 있다. 더욱 나쁜 것은, LFM(22)은 풍부한 ATP정보를 적절하게 제공하는 것이 불가능한 하위(inferior) ATP 서버(14)에 의해 지지(backed)될 수 있기 때문에, 이행 서버(16)는 부품 견적 또는 부품 계약의 여러 가지 복잡화(varied sophistication)를 처리하는 것을 필요로 할 수 있고, 그럼에도 불구하고 전체로서 ATP 요청(30)에 대한 최선의 가능한 견적 또는 계약을 작성(form)할 수 있다. 이 태스크를 적절하게 수행하기 위해서는 다양한 부품 견적이나 부품 계약을 해석하기 위한 또는 다양한 부품 견적이나 부품 계약을 적절히 변화(mutate)시키기 위한 소정 개수의 거래 제약조건을 요구할 수 있다. LFM(22)을 나타내는 모델 내에서의 확장성(extensibility)은 모델링되는 부품 견적 또는 부품 계약을 변화시키기 위한 다른 제약조건들을 허용한다. 본 발명은 본 명세서에서 설명된 모든 적절한 제약조건들과 관련하여 확장성을 꾀하려고 한다.
FP 엔진 상태와는 반대로, 여기서 ATP 서버(12)는 예를 들어, 주문 타이밍(order timing) 및 로트 크기 결정 제약조건뿐만 아니라 할당과 관련하여 보통 중요한 설명(representation)이 있는 SCP 엔진과 연관된다. 그 결과, LFM(22)은 이들 제약조건들을 부품 ATP 요청(32)으로부터 ATP 서버(14)에 전달할 수 있다.
특히 SCP 엔진과 관련하여, ATP 서버에의 최초의 견적 요청은 어떠한 할당된 제품이나 가용 자재(available material) 또는 용량(capacity)을 소비하지 않는 단지 문의(inquiry)일 수 있기 때문에, LFM(22)은 견적과 계약 작업흐름 사이의 구별이 필요할 수 있다. 견적 결과에 대한 응답은 ATP 서버(14)에서 LFM(22)으로 반환된다. 그러나, EDI 기반 교환(EDI-based exchanges)에서, ATP 서버(14)에의 견적 요청은 실제적으로 ATP를 소비하는 계약(ATP-consuming promise)으로 귀착될 수 있다.
LFM(22)는 원래의 부품 ATP 요청(originating component ATP request)(32)에 포함된 거래 제약조건들에 따라 ATP 서버(14)로부터의 견적 응답을 평가한다. 다시 한번, ATP 서버와 연관된 설계 엔진의 복잡화에 의존하는 이 평가의 요구조건들을 처리한다. SCP 엔진으로, 이 견적 응답은 LFM(22)의 프로세싱 책임이 제한되도록 거래 제약조건들을 포함(encompass)할 수 있다. 그러나 FP 엔진의 경우에 있어서는, LFM(22)은 부품 견적(34)이 생성되기 전에 견적 응답을 면밀히 검토할 필요가 있다. ATP 서버(14)는 각각이 적절한(applicable) 거래 제약조건들과 관련하여 평가되어야 하는 하나 이상의 견적 응답을 돌려 줄 수 있다.
ATP 서버(14)에서의 견적 응답에 대한 평가가 있은 후, LFM(22)는 어떻게 이행 서버(16)가 부품 견적(34)을 변화시킬 수 있을 것인지에 대한 제품 가용성 정보 및 규칙을 포함하는 부품 견적(34)을 산출한다. LFM(22)은 부품 견적(34)을 이행 서버(16)로 반환한다. 제약조건들에 따른 다수의 견적 응답이 유효한(valid) 것으로 간주되면, LFM(22)은 다수의 부품 견적(34)을 이행 서버(16)를 전송한다. 부품 ATP 요청(32)이 유효한 부품 견적(34)을 내는 데 실패하면, LFM(22)은 주석이 달린 실패 통지를 이행 서버(16)로 전송할 수 있다. 이러한 실패 통지는, 예를 들어 "제품 수량 부족(insufficient product quantities)" 또는 "선적을 위한 인도(shipment delivery) 또는 로트 크기 결정 요구조건을 충족시킬 수 없음" 등을 포함할 수 있다. 이하에서 설명하는 바와 같이, 이행 서버(16)는 제공하는 정보 및 규칙들에 따라 부품 견적(34)을 변경시켜, 부품 견적(34)이 이행 서버(16)에서공급되거나 ATP 요청(30)에 포함된 거래 제약조건들을 모두 충족하도록 한다.
부품 견적 속성(Component Quotation Attributes)
일 실시예에서, 각 부품 견적은 임의의 적절한 조합으로 다음의 속성을 갖거나 다음의 정보를 지원하며, 이에 한정되지 않는다; (1) 부품 견적 ID- LFM(22)이 부품 견적을 생성하는 경우, LFM(22)에서 할당됨; (2) 부품 요청 ID; (3) 이행 서버 ID; (4) 제품 ID- 대체물 또는 대용물이 명기되었을 수 있기 때문에 부품 요청에서 명기된 제품과 직접 일치하지 않을 수 있음; (5) 제품 UOM- ATP 서버(14)가 요청된 것이 아닌 다른 UOM으로 응답했을 수 있기 때문에, 부품 요청에서 명기된 것과 일치하지 않을 수 있음; (6) 계약 수량- 부품 견적 인도에 대한 제품의 수량; (7) 계약일- ATP 서버(14)에 의해 선적하기 위한 제품의 인도가 계약된 날짜; (8) 계약 로트; (9) 계약 속성들- 부품 견적에 대한 카테고리/속성 조합의 목록; (10) 계약 유형(promise type)- LFM(22)이 갱신하는 응답의 유형(예: "요청한 대로(as requested)", "대체/대용", "옵션" 등); (11) 단가(unit price)- ATP 서버(14)의 통화(currency)에 입각한 제품 단가; (12) 견적 상태- LFM(22)이 갱신하고, 견적이 실패 또는 성공하였는지를 나타냄; 및 (13) 실패 이유(failure reason)- LFM(22)이 평가하고, 갱신하며, 이행 서버(16)에 전송하는 견적이 실패한 이유의 간결한 설명(예: 공급 가용성 부족, 거래 제약조건들이 충족되지 않음 등);
부품 견적 프로세스(Process Component Quotations)[이행 서버]
일단 이행 서버(16)가 부품 ATP 요청(32)을 처리하여 LFM(22)에 전송하였으면, 이행 서버(16)는 부품 견적(34)에 대한 결과의 완료를 감시한다. 일 실시예에서, 견적(36)은 각 부품 ATP 요청(32)이 적어도 하나의 부품 견적(34) 또는 실패 통지를 수신한 경우 완료된 것으로 간주될 수 있다. 공급자는 부품 ATP 요청(32)에 다수의 수락 가능한 ATP 옵션으로 응답할 수 있다. 이행 서버(16)는 다차원(예를 들어, 제품 옵션, 리드 타임(lead time) 및 가격 등)의 견적을 생성하고 클라이언트(12)로 전송하기 위하여 이러한 부품 견적(34)을 사용한다. 모든 부품 견적(34)이 수신되어 견적(36)이 완료된 경우, 이행 서버(16)는 원래의 ATP 요청(30)에 명기된 거래 제약조건에 따라 전체로서 견적(34)을 평가한다. 그 결과로서, 이행 서버(16)는 ATP 요청(30)의 요구조건들이 충족되었는지를 결정하고, 클라이언트(12)에게 제공되는 통합된 견적(36)에서 모든 합치하지 않는(non-conforming) 공급자의 응답을 골라낸다. 일 실시예에서, 이행 서버(16)는 그들이 제공하는 정보 및 규칙에 따라 부품 견적(34)이 ATP 요청과 함께 포함되거나 이행 서버(16)에서 제공한 거래 제약조건을 모두 충족시키도록 부품 견적(34)을 변화시킨다. 몇몇 클라이언트(12)는 다차원 견적(36)을 취급할 수 없기 때문에, 이행 서버(16)의 클라이언트 인터페이스가 또한 특정 요구에 따라 견적 정보의 더욱 제한적인 사용을 위해 제공될 수 있다.
일반적으로, 이행 서버(16)는 고객 및 공급자의 거래 제약조건에 대한 자신의 견적(36) 평가(assessment)에 따라 "가장 적합한(best fit)" 응답을 클라이언트(12)에 제공하는 것을 시도한다. 예를 들어, 만약 ATP 요청(30)의 정시 선적 속성은 정시에 선적되어야 하는 것을 지정하고, 이행 서버(16)는 ATP 요청(30)에 대한 실패 상태를 할당할 수 있으며, 하나 이상의 부품 견적(34)이 다소 불충분하여, 이행 서버(16)가 실패 상태를 ATP 요청(30)에 대해 완전히 실패 상태를 할당할 수 있다. 이행서버(16)는 간단히 클라이언트(12)에 LFM(22)으로부터 수신된 실패 상태 주석을 전달할 수 있다. 이 대신에 또는 이에 추가하여, 이행 서버(16)는 자신이 가지고 있는 실패 평가 주석을 할당할 수 있다. 예를 들어, LFM(22)이 유효한 부품 견적(34)을 생성하였을 동안에, 이행 서버(16)는 고객의 거래 제약조건을 충족하지 않는 견적 가격에 기초하여 전체 견적(36)의 실패를 결정할 수 있다. 특정 요청 품목이 다수의 부품 견적을 산출하는 경우, 각 부품 견적(34)은 명기된 제약조건과 관련하여 평가되어야 한다. 요청 품목에 대한 모든 유효한 부품 견적(34)은 네트워크(18)를 이용하여 견적(36)의 형태로 클라이언트(12)에 전송된다.
ATP 서버 응답이 하나 이상의 사항(제품, 리드 타임 또는 가격에 기초하여 단독으로 또는 임의의 조합으로)을 충족하면, 이행 서버(16)는 클라이언트(12)로 전달하기 위해 견적(36)을 생성하기 전에 추가적인 기능들을 수행할 수 있다. 예를 들어, 클라이언트(12)는 가격책정(pricing), 세금(taxes), 화물 운송(freight) 또는 인도 스케줄의 계산을 요구할 수 있다. 구현 방법에 따라서는, 이것은 특정 루틴을 사용하여 달성될 수 있거나, 예를 들어 수송 및 로지스틱스 설계 팩키지(logistics planning packages)에 의존하는 하나 이상의 배경 설계 프로세스(background planning processes)의 통합을 포함할 수 있다. 이러한 "보조(auxiliary)" 프로세스들의 사용은 클라이언트(12)가 모든 또는 일부의 견적(36)을 확인할 때까지 임의로 지연될 수 있다.
일 실시예에서, 이행서버(16)는 고객의 요구에 따라 동작하는 가격책정 엔진 구성요소(pricing engine component)를 제공한다. 예를 들어, 이행 서버(16)는 패키지화된(packaged) ERP 시스템과 함께 구현될 수 있으며, 고객은 가격책정이 ERP 시스템의 한계(bondaries) 내에서 처리되도록 선택할 수 있다. 일 실시예에서, 이행 서버(16)가 가격책정을 관리하고, 각 부품 견적(34)이 먼저 목록에서 가격을 산출(priced out)을 한 다음, 미리 명기된 품목(pre-specified line), 요청 또는 용량 레벨 프로그램(volume-level programs)에 기초하여 일반적인 할인이 적용된다. 소정의 ATP 요청(30)에 대해 다수의 할인을 적용할 수 있다. 가격책정 및 할인 프로그램은 고객, 고객의 위치(customer location), 공급자, 계약(agreement), 제품 그룹(product group) 또는 다른 임의의 적당한파라메터나 파라이터의 집합에 따라 지정될 수 있다.
이행 서버(16)의 다차원 응답 성능(reponse capability)은 가격책정 기능성에 관련하여 특수한 문제를 발생시킬 수 있다. 즉, 하나 이상의 옵션이 사용자에게 제공되는 경우에 특정 요청 품목에 대해 이행 서버(16)가 할인을 목적으로 전체로서 그 순서(order)를 평가하는 것이 어려울 수 있다. 다수의 부품 견적(34)은 특정 부품 ATP 요청(32)을 위하여 존재하고, ATP 요청(30)에 대한 가격책정은 일반적으로 단순히 할인액(discount)을 총합하여 나타낼 수 없다. 대신에, ATP 요청 가격은 최소 및 최대 한계를 갖는 범위가 된다. 이점에서, 가격책정은 다시 계산되고 사용자에게 계약 확인으로 제공된다.
이행 서버(16)가 ATP 요청(30)의 명기된 계약조건에 관련하여 견적(36)의 평가를 완료한 경우, 견적(36)은 이러한 요구조건을 충족하는 것으로 결정되었고, 이행 서버(16)는 견적(36)을 검토(review) 및 견적 확인(quotation confirmation)을 위하여 클라이언트(12)에 전송한다. 요청을 한 클라언트(12)가 더 이상 활성 상태(active)가 아니면, 견적(36)은 다음에 질의(query)를 받을 때까지 저장될 수 있다. 견적(36)의 구성(structure)은 원래의 ATP 요청(30)의 구성을 모델링한다. 그러나, 견적(36)은 각 요청 품목 및 요청 품목 인도에 대한 다수의 응답을 포함할 수 있기 때문에 ATP 요청(30)보다 잠재적으로 더 복잡할 수 있다.
견적 속성(Quotation Attributes)
일 실시예에서, 견적은 임의의 적당한조합으로 다음의 속성을 갖거나 다음의 정보를 지원하는 객체이며, 이에 한정되지 않는다: (1) 견적 ID- 이행 서버(16)에서 할당되고 요청 ID와 동일할 수 있음; (2) 요청 ID(request ID); (3) 최대 전체 가격(maximum total price)(기준 통화)- 이행 서버(16)에서 기준 통화(base currency)로 계산된 견적의 최대 전체 가격으로 가격 견적의 상한(upper bound)을 나타냄; (4) 최소 전체 가격(minimum total price)(기준 통화)- 이행 서버(16)에서 기준 통화로 계산된 견적의 최소 전체 가격으로 가격 견적의 하한(lower bound)을 나타냄; (5) 최대 전체 가격(고객 통화)- 이행 서버(16)에서 사용자가 선택한 통화(customer-preferred currency)로 계산된 견적의 최대 전체 가격; (6) 최소 전체 가격(고객 통화)- 이행 서버(16)에서 고객이 선택한 통화로 계산된 견적의 최소 전체 가격; (7) 견적 상태(quotation status)- 견적이 생존하는 동안 이행 서버(16)가 갱신함(예: "견적 실패", "수락중", "수락", "거절", "수락 미수신" 등); (8)수락일- 견적 확인이 처리되었다면 그 날짜 및 시간; (9) 거절일- 견적이 거절되었다면 그 날짜 및 시간.
견적 품목 속성(Quotation Line-Item Attributes)
일 실시예에서, 견적 품목은 임의의 적당한조합으로 다음의 속성을 갖거나 다음의 정보를 지원하는 객체이며, 이에 한정되지 않는다: (1) 품목 ID- 이행 서버(16)에서 할당되며, 요청 품목에 대한 다수의 견적 응답을 조정함(accommodating); (2) 견적 ID- 견적을 견적 품목에 연결함; (3) 제품 ID- 대체물 또는 대용물이 대신 견적되었을 수 있기 때문에 원래의 요청 품목에서 명기된 제품과 직접 일치하지 않을 수 있음; (4) 제품 UOM- ATP 서버(14)가 요청된 UOM과 다르게 응답하였을 수 있기 때문에 원래의 요청 품목에서 명기된 UOM과 일치하지 않을 수 있음; (5) 제공된 수량(offered quantity)- 견적 품목과 관련된 수량; (6) 제공일(offerd date)- 수량이 입수 가능하게 될 날짜이며, 실행(implementation)함에 따라 ATP 서버(14)에 의해 소정의 선적일을 나타내거나 조정된 고객이 원하는 인도 날짜; (7) 제공된 로트(offered lot)- 견적 품목에 대한 로트 식별자(lot identifier); (8) 제공된 속성(offered attribute)- 견적 품목에 대한 카테고리/속성 조합들의 목록; (9) 견적 유형(quotation type)- 응답의 유형(예: "요청한 대로", "대체물/대용물", "옵션" 등); (10) 제공된 단가(offered unit price)(기준 통화)- 이행 서버(16)의 기준 통화로 나타낸 견적 품목에 관련된 단가; 제공된 전체 가격(기준 통화)- 이행 서버(16)의 기준 통화로 나타낸 견적 품목에 관련하여 계산된 전체 가격; (12) 제공된 단가(고객 통화)- 고객이 선택한통화로 표현된 견적 품목에 대한 단가; (13) 제공된 전체 가격(고객 통화)- 고객이 선택한 통화로 표현된 견적 품목에 대해 계산된 전체 가격; (14) 견적 품목 상태- 이행 서버(16)가 대응하는 부품 견적상태에 기초하여 갱신하는 논리 파라메터이고, 요청 품목이 수락 가능한 견적을 얻는데 성공하였는지 또는 실패하였는지를 나타냄; (15) 실패 이유- 견적 실패에 대한 이유의 간결한 설명; (16) 견적 품목 수락 상태(quotation line-item acceptance status)- 견적 품목이 수락되었는지 또는 거절되었는지를 나타내며, 이행 서버(16)가 LFM(22)에 부품 견적 확인 트랜잭션을 생성하는 데 사용됨.
일 실시에에서, 견적 품목 인도는 임의의 적당한조합으로 다음의 속성을 갖거나 다음의 정보를 지원하는 객체이며, 이에 한정되지 않는다: (1) 견적 품목 인도 ID- 이행 서버(16)에서 할당되고 요청 품목 인도에 대한 다수의 견적 응답을 조정함; (2) 견적 품목 ID; (3) 제공된 수량; (4) 제공일; (5) 제공된 로트; 및 (6) 제공된 속성.
견적 확인 작업흐름(Quotation Confirmation workflow)
도 3은 예시적인 견적 확인 작업흐름을 도시한 것으로, 클라이언트(12)가 견적(36), 그리고 어쩌면 연관된 사용자로부터 입력되는 것에 기초한 견적 확인을 생성시킨다. 클라이언트(12)는 견적 확인(40)을 이행 서버(16)로 전송하고, 이는 이행 서버(16)에서 분석되고 평가된다. 이행 서버(16)는 부품 견적 확인(42)의 결과를 네트워크(20)를 이용하여 LFM(22)에 전송하고, LFM(22)은 자신과 연관된 ATP 서버(14)와 협력하여 부품 견적 확인(42)을 처리하며, 이에 따라 LFM(22)은 부품 계약(44)을 생성한다. 그런 다음, LFM(22)은 부품 계약(44)을 이행 서버(16)로 반환한다. 이행 서버(16)는 부품 계약(44)을 처리하고, 하나로 통합된 계약(46)을 생성시켜, 생성된 계약(46)을 검토 및 확인을 위해 클라이언트(12)로 전송한다.
견적 확인 생성(Generate Quotation Confirmation)[클라이언트]
견적(36)이 수신된 경우, 클라이언트(12) 또는 연관된 사용자는 이를 검토하여 하나 이상의 개별 견적 품목을 선택적으로 수락 또는 거절하거나 견적(36)을 전체로서 수락 또는 거절할 수 있다. ATP 서버의 성능 및 ATP 요청(30)에 관련된 거래 제약조건에 따라 하나 이상의 유효한 옵션이 소정의 요청 품목에 대해 만들어질 수 있다. 그런 다음, 클라이언트(12) 또는 연관된 사용자는 견적(36)을 수락하기 전에 다수의 옵션으로부터 전부 또는 일부를 선택할 수 있다. 일단 이 프로세스가 완료되었으면, 클라이언트(12)는 수락과 거절을 모두 포함하는 견적 확인(40)을 처리를 위해 이행 서버(16)로 전송한다. 견적 확인(4)은 견적(36)의 부분집합(subset)만을 수락할 수 있기 때문에, 견적(36)이 아니라 견적 확인(40)이 계약(46) 결과의 근거를 이룰 것이다. 클라이언트(12)가 견적(36)이 수락 불가능하다고 생각하면, 클라이언트(12)는 ATP 요청(30)을 이후에 다시 제출(re-submission)하기 위하여 큐(queue)에 저장할 수 있다. 디폴트 제약조건은 특정 요구에 따라 다시 제출(재견적) 요청의 기간과 빈도를 지정한다.
일 실시예에서, 견적 확인(40)은 임의의 적당한조합으로 다음의 속성을 갖거나 다음의 정보를 지원하는 객체이며, 이에 한정되지 않는다: (1) 견적 ID; (2) 견적 품목 ID; 및 (3) 견적 품목 상태- 견적 품목이 수락, 거절, 취소 또는 큐잉되었는지를 나타내며, 이행서버(16)에서 LFM(22)에 제출하기 위한 부품 견적 확인(42)을 생성하기 위해 사용됨.
견적 확인 프로세스(Process Quotation Confirmation)[이행 서버]
견적(36)은 제품 가용성(product availability)에 대한 구속력 없는(non-binding) 계산서이다. 일단 클라이언트(12)가 견적(36)을 전부 또는 일부 수락하면, 이행 서버(16)는 적절한 각각의 ATP 서버 위치에서 할당된 공급량(supply)을 소비하는 LFM(22)의 전체 분산 네트워크(distributed network)에 견적 확인(40) 결과의 처리를 맡긴다. 일 실시예에서, ATP 요청(30)은 각각의 개별 위탁 위치(respective commitment locations)(LFM(22))에서 감시되고 유지되는, 분산되고 지속적인(persistent) 객체이다. 따라서, ATP 요청(30)이 이행되거나 취소될 때까지 부품 ATP 요청(32)은 이행 서버(16)가 지능적으로 관리하는 분산된 주문 잔고(order backlog)의 일부로 남는다.
일 실시예에서, 이행 서버(16)는 클라이언트(12) 또는 연관된 사용자로부터의 전부 또는 일부 수락, 거절, 재견적, 취소, 문의(inquiries) 및 다른 임의의 적당한사용자 응답을 포함하는 다양한 응답을 처리할 수 있다. 품목 견적이 수락되면, 그 수락은 LFM(22)이 보통 대응하는 부품 견적(34)에 기초하여 공급량을 예약(supply reservation)하지 않을 것이기 때문에 LFM(22)에서 확인되어야 한다. 그러나 예약한 공급량이 부족한 결과로서, 품목 견적을 실패할 수 있으며, LFM(22)이 적절하다면 어떤 조치(action)를 취할 수 있도록 이행 서버(16)는 LFM(22)에 통지할 필요가 있다. 일 실시예에서, 이행 서버(16)는 LFM(22)에 부품 견적(34)과함께 부품 계약(44)을 제공하도록 요청할 수 있지만, 수락 기한의 날짜(accept_by date)가 상대적으로 촉박할 수 있다. 그런 다음, 이행 서버(16)는 클라이언트(12)로부터 견적 확인(40)을 수신한 경우에 부품 계약(44)을 수락할 수 있다. 이행 서버(16)는 적절히 수락 기한의 날짜와 결합하여 특정 ATP 요청(30)에 연관된 LFM(22)으로부터 적절히 태스킹 된다. 수락 기한 날짜의 결과는 일반적으로 이행 서버(16)가 견적(36)(또는 계약(46))을 계산하는 시간을 고려해야 하고, 얼마간의 시간 여유(padding)를 포함하도록 하는 것이 바람직하다. 대부분의 LFM(22)에서의 응답이 실제로 고객에게 제품이 인도될 날짜를 반영할 수 없기 때문이 아니라, 공급자의 선적 스케줄 일람표(statements of supplier shipment schedules)로 대신할 수 있기 때문에, 이행 서버(16)는 다수 품목 주문(multi-item order)에 대한 고객에의 인도일을 생성시키는 능력을 제 할 수 있고, 어쩌면 계약 실행(promise action)에 대해 선택적인 다음 처리 단계(post-processing step)로서 제공할 수 있다.
앞서 설명한 바와 같이, 견적 확인(40)은 수락, 거절, 취소 또는 큐에 저장 등과 같은 각 견적 품목의 상태를 지정하는 객체일 수 있다. 이행 서버(16)는 부품 견적(34)에 대응하는 상태를 나타내며, 품목 기준에 따라 거절(rejection)된 것들에서 수락(acceptances)할 것들을 골라내고, LFM(22)에 제출하기 위한 부품 견적 확인(42)을 생성한다. 이행 서버(16)는 원래의 부품 ATP 요청(32)의 상태를 "계약중"으로 갱신한다. 일 실시예에서, 부품 견적 확인(42)은 임의의 적당한조합으로 다음의 속성이나 다음의 정보를 지원하는 객체이며, 이에 한정되지 않는다: (1) 부품 견적 ID; (2) LFM ID; 및 (3) 부품 견적 상태- 부품 견적이 수락, 거절 또는 취소되었는지를 나타냄.
부품 견적 확인 프로세스(Process Component Quotation Confirmation)[LFM]
LFM(22)은 부품 견적 확인(42)을 수신하고, 설계 엔진과 관련된 적절한 명령 구문을 사용하여 ATP 서버(14)로 계약 요청을 발생시킨다. 이 트랜잭션(transation)은 ATP 서버(14)에서 제품 할당량(product allocation)이나 입수 가능한 자재(available materials) 또는 용량(capacity)에 대한 확고한 매매 계약(firm commitment)을 찾는 것을 제외하고, 원래의 부품 요청 트랜잭션과 유사하다. 또한 확인 트랜잭션은 원하는 부품 견적(34)에 대응하는 매매 계약을 확인하여야 하며, 원래의 부품 ATP 요청(32)이 다수의 부품 견적(34)을 수신하면 LFM(22)은 사용자가 클라이언트(12)에서 명기한 특정 견적 응답을 반드시 확인하도록 하여야 한다. 이 시점(point)에서, ATP 서버(14)는 적당한 할당된 제품이나 입수 가능한 자재 또는 용량을 소비하는 확고한 계약으로 응답한다. 어떤 경우에는, 이 시점에서 수락을 발생시키는 것이 또한 적당할 수 있다. LFM(22)은 거절 명령 또는 클라이언트(12)로부터 다른 소정의 정보에 근거하여 거절된 부품 견적(34)을 제거할 수 있다.
LFM(22)는 이행 서버(16)가 부품 계약(44)을 변경시킬 수 있는 방법에 대한 정보와 규칙(rules)을 포함하는 부품계약(44)을 계산한다. ATP 서버(14)로부터 계약 응답이 수신된 경우에, LFM(22)은 계약 응답이 원래의 부품 견적(34)과 다를 수 있기 때문에 응답이 부품 견적 확인(42)과 일치하는지를 보증하기 위하여 그 응답을 평가한다. 이것은, 예를 들어 어디서 설계 변경(planning change)이 제품 가용성을 어떻게든 변경했는지, 또는 언제 다른 부품 견적 확인(42)이 그사이에 소비되는 제품 할당으로 귀착되었는지를 발생시킬 수 있다. 이것이 발생하는 경우, LFM(22)은 이 상태(condition)를 기록하고, 부품 ATP 요청(32)에서 명기된 거래 제약조건을 여전히 충족하는 계약 응답인지를 평가한다. 만약 그렇다면, LFM(22)은 ATP 서버(14)로부터의 계약 응답에 따라 부품 계약(44)을 생성한다. 만약에 다수의 계약 응답이 제약조건에 따라 유효한 것으로 간주되면, LFM(22)은 다수의 부품 계약(44)을 생성하여 이행 서버(16)에 반환한다. 부품 계약(44)이 어떻게든 원래의 부품 계약(34)과 다르면, 이것은 부품 계약(44)으로 기록될 수 있다. 부품 계약(44)이 더 이상 부품 ATP 요청(32)에서 명기된 거래 제약조건을 따르지 않으면, LFM(22)은 이행 서버(16)로 전달하기 위한 주석이 부가되거나 또는 다른 적당한 실패 통지를 생성할 수 있다. 주석의 예로는 "제품 수량 부족" 또는 "선적 인도 또는 로트 크기 요구조건을 충족시키지 못함" 등을 포함할 수 있다.
일 실시예에서, 부품 계약(44)은 임의의 적당한조합으로 다음의 속성을 갖거나 다음의 정보를 지원하는 객체이며, 이에 한정되지 않는다: (1) 부품 계약 ID- LFM(22)이 부품 계약을 생성하는 경우 할당되고, 부품 견적 ID와 동일할 수 있음; (2) 이행 서버 ID; (3) 수락 기한- 수락이 수신되어야 하거나 대응하는 계약 예약이 해제될 수 있는 부품 계약의 만료일을 나타낼 수 있음; (4) 부품 계약 상태- 부품 계약이 성공하였는지 또는 실패하였는지를 나타냄; (5) 실패 이유- 계약이 실패하였다면 그 이유에 대한 간결한 설명.
부품 계약 프로세스(Process Component Promises)[이행 서버]
일단 이행 서버(16)가 부품 견적 확인(42)을 처리하였으면, 그것을 LFM(22)으로 전송하고 부품 계약(44)의 결과 완료를 감시한다. 일 실시예에서, 계약(46)은 각각의 원래의 부품 견적 확인(42)이 하나 이상의 부품 계약(44) 또는 실패 통지를 수신한 경우 완료된 것으로 간주된다. 또한 이행 서버(16)는 이행 서버(16)가 LFM(22)로부터의 부품 계약을 위해 대기하여야 하는 기한을 지정하는 계약 기한(promise_by) 속성을 감시할 수 있다. 이 제약조건이 모든 부품 계약(44)이 수신되기 전에 도달되어 해당 견적 확인(40)이 반드시 기한이 만료(expired)되도록 하는 경우, 이행 서버(16)는 적당한 실패 통지를 발생시킬 수 있고, 그것을 클라이언트(12)로 전송한다. 정식 계약(formulating promise)(46)에서, 이행 서버(16)는 모든 수락 기한(accept_by) 속성을 참작할 수 있으며, 계약(46)에 대한 수락 기한 속성을 적절히 명기한다.
일 실시예에서, 일단 부품 계약(44)이 만료하면, 이행 서버(16) 및 적절한 LFM(22)은 공급 예약(reservation of supply)을 해제한다. 이행 서버(16)에는 LFM(22)보다 엄격한 수락 기한 날짜가 제공되고, 이행 서버(16)는 해제 지시(indication of release)를 LFM(22)으로 반환할 필요가 있다. 마찬가지로, 계약(46)이 실패하거나 거절되면, 이행 서버(16)는 LFM(22)이 적절한 공급량 예약을 해제할 수 있도록 LFM(22)에 통지한다.
이행 서버(16)가 부품 계약(44)을 LFM(22)으로부터 수신하고 계약(44)이 완료하는 경우, 이행 서버(16)는 전체 응답의 성공을 재평가하기 위하여 전체계약(44)을 원래의 ATP 요청(30)에서 명기한 거래 제약조건에 따라 평가한다. 하나 이상의 부품 계약(44)이 원래의 부품 견적(34)과 상이할 수 있으므로 이것은 계약 생성 단계(promise generation) 동안에 다시 실행된다. 어떤 부품 계약(44)이 원래의 부품 견적(34)과 상이하면, 가격책정 또한 계약 생성 단계 동안에 다시 계산될 필요가 있다. 게다가, 특정 부품 ATP 요청(32)에 대해 다수의 부품 견적(34)이 존재하면, 최종 확인 가격(final confirmed price)의 계산은 필수적일 수 있다. 일 실시예에서, 모든 부품 계약(44)은 계약(46)을 성공적으로 달성하기 위하여 유효하여야 한다.
일 실시예에서, 이행 서버(16)는 부품 계약(44)이 제공하는 정보 및 규칙에 따라 부품 계약(44)을 변경하거나 조작하여, 부품 계약(44)이 이행 서버(16)에서 적용되거나 ATP 요청(30)에 함께 주장된 거래 제약조건을 모두 만족시키도록 할 수있다. 계약(44)을 클라이언트(12)에 전송하는 것에 더하여, 이행 서버(16)는 변경된 부품 계약(44)을 원래의 LFM(22)에 반환하여, 이 LFM(22)이 공급량 예약을 적절하게 조절할 수 있도록 한다.
견적(36)과 계약(46) 사이의 기간동안에 제품 가용성의 변경에 기인하거나 다른 이유 때문에 전체 응답이 더 이상 ATP 요청(30)의 요구조건을 충족시키지 않으면, 이행 서버(16)는 계약(46)에 대해 실패 상태를 할당할 수 있으며, 클라이언트(12)에게 계약(46)을 전송하기 전에 정보를 설명하는 주석을 단다. 이행 서버(16)는 LFM(22)로부터 수신된 실패 상태 주석과 함께 단순히 전달할 수 있다. 이 대신에 또는 이에 추가하여, 이행 서버(16)는 자신의 주석을 할당할 수 있다.예를 들어, 비록 LFM(22)이 수락 가능한 부품 계약(44)을 생성하였다고 해도, 이행 서버(16)는 계약 가격책정이 고객의 명기된 거래 제약조건을 충족시키지 못하는 것을 근거로 계약(46)이 전체로서 실패한 것으로 결정할 수 있다.
이행 서버(16)는 고객의 요구조건에 따라 결정되는 인도 조정(delivery coordination) 엔진 구성요소를 포함할 수 있다. 이러한 능력 (capability)이 없으면, 이행 서버(16)는 고객에게 개개의 제조 및 분배 장소에서의 인도일(delivery date)을 돌려주는(return) 것보다 최적의 선적일(shipment date)을 돌려주는 것이 낫다. 인도 조정은 제품, 장소 및 표준 리드 타임을 연결하는 상대적으로 간단한 표 조작 기술(table-driven techinque)을 사용하여 달성할 수 있다. 더 복잡한 구현에는 수송 및 로지스틱스 최적화를 위한 진보된(advanced) 설계 엔진의 사용을 포함할 수 있다. 이 시나리오에서, 인도 조정은 여러 단계(multiple phase)에서 계산될 수 있는 것과 유사하다.
예를 들어, 표 기반(table-based) 표준 리드 타임 접근은 최초의 계약 생성 단계에서 예비적인 인도 날짜를 얻기 위해 사용될 수 있다. 수송 계획 최적화(transportation planning optimization)는 일반적으로 인도에 대해 다수의 요구조건이 고려되는 경우에 가장 효과적이기 때문에, 일괄 지향 처리(batch-oriented processing)의 두 번째 단계는 전체 요청 잔고(entire request backlog)를 평가하는 것이 바람직할 수 있다. 이러한 두 번째 단계의 처리 결과로서, 개별 ATP 요청(30)에 대응하는 인도 날짜는 최적화된 전체 인도 계획을 반영하기 위해 조정될 수 있다.
이행 서버(16)가 계약(46)의 평가를 완료하였고, 가격책정 및 인도가 적절히 계산되었으며, 또 모든 응답이 여전히 충족하는 것으로 간주되는 경우에, 이행 서버(16)는 확인을 위하여 계약(46)(모든 유효한 부품 계약(44)을 포함함)을 클라이언트(12)로 전송한다. 계약(46)의 구성(structure)은 그것의 원래 견적(36)으로부터 모델링하지만, 계약(46)이 불연속(discrete)적인 까닭에 견적(36)이 다차원이었을 수 있으므로 견적 상대(quotation counterpart)보다 어쩌면 더 단순할 수 있다. 클라이언트(12)의 요청이 더 이상 활성 상태가 아니면, 계약(46)은 이후의 시점에서 질의될 수 있다.
계약 속성(Promise Attributes)
일 실시예에서, 계약(44)은 임의의 적당한조합으로 다음의 속성을 갖거나 다음의 정보를 지원하는 객체이여 이에 한정되지 않는다: (1) 계약 ID- 이행 서버(16)에서 할당되고 견적 ID와 동일할 수 있음; (2) 전체 가격(기준 통화)- 이행 서버(16)에서 기준 통화로 계산된 계약의 전체 가격; (3) 전체 가격(고객 통화)- 이행 서버916)에서 고객이 선택한 통화로 계산된 계약의 전체 가격; (4) 전체 세금(total tax)(기준 통화)- 이행 서버(16)에서 기준 통화로 계산된 요청에 관련된 전체 세금; (5) 전체 세금(고객 통화)- 이행 서버(16)에서 고객이 선택한 통화로 계산된 요청에 관련된 전체 세금; (6) 확인일(date confirmed)- 계약이 처리된 날짜 및 시간; (7) 수락 기한- 수락이 수신되어야 하거나 일부 또는 모든 관련된 계약 예약이 해제될 수 있는 계약의 만료일을 나타낼 수 있음; (8) 취소일- 계약이 취소되었다면 그 날짜 및 시간; 및 (8) 선적일(date shipped)- 계약이 이행되었다면 그 날짜 및 시간.
계약 품목 속성(Promise Line-Item Attributes)
일 실시예에서, 계약 품목은 임의의 적당한조합으로 다음의 속성을 갖거나 다음의 정보를 지원하는 객체이며, 이에 한정되지 않는다: (1) 계약 품목 ID- 이행 서버(16)에서 할당되고 견적 품목 ID와 동일할 수 있음; (2) 계약된 제품에 대한 제품 ID; (3) 계약된 제품에 대한 제품 UOM; (4) 계약 품목에 대해 계약된 수량; (5) 계약된 선적일(promised ship date)- 계약된 수량이 선적 가능하게 될 날짜이고, ATP 서버(14)에서 주어진 선적일을 나타냄; (6) 고객 인도일(customer delivery date)- 계약된 수량이 지정된 고객의 선적 장소에 도착하게 될 날짜이고, 이것은 수송 계획 및 로지스틱스 엔진을 사용하여 계산되고 갱신될 수 있음; (7) 계약 로트(promised lot); (8) 계약 속성(promised attributes); (9) 계약 유형(promise type)- 계약 품목에 대한 응답의 유형(예: "요청한 대로", "대체/대용", "옵션" 등); (10) 계약 단가(promised unit price)(기준 통화)- 이행 서버의 기준 통화로 계산된 단가; (11) 계약 전체 가격(기준 통화)- 이행 서버에서 기준 통화로 계산된 전체 가격; (12) 계약 단가(고객 통화)- 고객이 선택한 통화로 계산된 단가; (13) 계약 전체 가격(고객 통화)- 고객이 선택한 통화로 계산된 전체 가격; (14) 계약 품목 상태- 요청 품목이 수락 가능한 계약 응답을 얻는 데 성공하였는지 또는 실패하였는지를 나타내는 대응하는 부품 계약의 상태에 따라 이행 서버(16)가 갱신함; (15) 수락 기한- 수락이 수신되어야 하거나 관련된 계약의 예약이 해제될 수 있을 때까지의 계약 품목에 대한 만료일을 나타낼 수 있음; (16) 실패 이유; (17) 선적 날짜/시간; 및 (18) 취소일.
일 실시예에서, 계약 품목 인도는 임의의 적당한조합으로 다음의 속성을 갖거나 다음의 정보를 지원하는 객체이며 이에 한정되지 않는다: (1) 계약 품목 인도 ID- 이행 서버(16)에서 할당되고, 어쩌면 견적 품목 인도 ID와 동일함; (2) 계약된 수량; (3) 계약된 선적일; (4) 고객 인도일; (5) 계약된 로트; 및 (6) 계약 속성.
계약 수락 작업흐름(Promise Acceptance Workflow)
도 4는 예시적인 계약 수락 작업흐름을 도시한 것으로, 클라이언트(12)는 계약(46) 그리고 어쩌면 연관된 사용자로부터의 입력에 기초하여 수락(50)을 생성한다. 클라이언트(12)는 이 수락(50)을 이행 서버(16)로 전송하고, 이행 서버(16)에서 수락(50)은 분해되고 평가된다. 그런 다음, 이행 서버(16)는 네트워크(20)를 이용하여 LFM(22)으로 부품 수락(52)의 결과를 전송하고, LFM(22)은 관련된 ATP 서버(14)와 협력하여 부품 수락(52)을 처리하며, LFM(22)은 부품 수락 확인(54)을 적절히 생성한다. LFM(22)은 이행 서버(16)로 부품 수락 확인(54)을 반환하고, 여기서 부품 수락 확인(54)은 최종 수락 확인(56)이 네트워크(18)를 이용하여 클라이언트(12)로 전송될 수 있도록 처리되어, 사이클(cycle)을 완료한다.
이 작업흐름은 대화형의(interactive) 수락 시나리오를 설명하지만, 본 발명은 일반적으로 EDI-기반 작업흐름에 연관된 것과 같은 비 대화형(non-interactive) 수락 처리도 의도한다(contemplate). 어떤 경우에, 견적 확인과 계약 수락 프로세싱을 동시에 수행하는 것이 적절할 수 있다. 그러나 제품 가용성이 견적 확인(40)과 수락(50) 사이의 시간 간격에서 변화할 가능성이 있다면, 대화형의 견적 확인과계약 수락 프로세싱을 분리하는 것이 적절하다. 이 경우에, 계약(46)이 더 이상 견적(36)을 반영하지 않는 다면, 사용자는 임의로 계약(46)을 거절할 수 있는 능력을 원할 수 있다. 이러한 유형의 시나리오는 SCP 기반 ATP 서버 환경에서 지정될 수 있다. 해당 기술분야의 당업자는 EDI 기반 및 다른 적당한 작업흐름을 조정하는 시스템(10)과 이러한 모든 작업흐름을 포함하는 본 발명의 진가를 인정할 것이다.
수락 생성(Generate Acceptance)[Client]
일단 클라이언트(12) 또는 연관된 사용자가 평가된 계약(46)을 이행 서버(16)로부터 수신하였으면, 클라이언트(12) 또는 사용자는 계약(46)을 전부 또는 일부 수락할 수 있다. 클라이언트(12)는 원래의 ATP 요청(30)에 대응하는 정식(formal) 수락(50)을 생성하고, 처리를 위해 이를 이행 서버(16)로 전송한다.
수락 속성(Accptance Attributes)
일 실시예에서, 수락(50)은 임의의 적당한조합으로 다음의 속성을 갖거나 다음의 정보를 지원하는 객체이며, 이에 한정되지 않는다: (1) 수락 ID- 이행서버(16)에서 할당되고 견적 ID 및 계약 ID와 동일할 수 있음; (2) 전체 가격(기준 통화); (3) 전체 가격(고객 통화); (4) 전체 세금(기준 통화)-; (5) 전체 세금(고객 통화); (6) 수락일(date accepted)- 수락이 처리된 날짜 및 시간; (7) 취소일- 수락이 취소된 날짜 및 시간; (8) 선적일- 수락이 이행된 날짜.
일 실시예에서, 수락 품목은 임의의 적당한조합으로 다음의 속성을 갖거나 다음의 정보를 지원하는 객체이며, 이에 한정되지 않는다: (1) 수락 품목 ID- 이행서버(16)에서 할당되고, 견적 품목 ID 및 계약 품목 ID와 동일할 수 있음; (2) 제품 ID; (3) 제품 UOM; (4) 수락 품목에 대한 계약 수량; (5) 계약된 선적일; (6) 고객 인도일; (7) 수락된 로트- 수락 품목에 관련된 로트 식별자(identifiers); (8) 수락 속성- 수락 품목에 관련된 카테고리/속성 조합의 목록; (9) 수락 유형- 수락 품목에 대한 응답의 유형(예: "요청한 대로", "대체/대용", "옵션" 등); (10) 수락 단가(기준 통화)- 계약 단계(promising phase)에서 계산되었을 이행 서버의 기준 통화로 나타낸 수락 품목에 대한 단가; (11) 수락 전체 가격(기준 통화로)- 계약단계에서 계산되었을 이행 서버의 기준 통화로 나타낸 수락 품목에 대해 계산된 전체 가격; (12) 수락 단가(고객 통화)- 계약단계에서 계산되었을 고객이 선택한 통화로 나타낸 수락 품목에 대한 단가; (13) 수락된 전체 가격(고객 통화)- 계약단계에서 계산되었을 고객이 선택한 통화로 나타낸 수락된 품목에 대해 계산된 전체 가격; (14) 수락 품목 상태- 이행 서버(16)가 대응하는 부품 계약 상태에 기초하여 갱신하는 논리 파라메터이며, 요청 품목이 적절한 수락을 얻는 데 성공하였는지 또는 실패하였는지를 나타냄; (15) 실패 이유- 수락이 실패하였다면 그 이유에 대한 간결한 설명; (16) 선적일- 수락 품목이 선적되었다면 그 날짜 및 시간; 및 (18) 취소일- 수락 품목이 취소되었다면 그 날짜 및 시간.
일 실시예서, 수락 품목 인도는 임의의 적당한조합으로 다음의 속성을 갖거나 다음의 정보를 지원하는 객체이며, 이에 한정되지 않는다: (1) 수락 품목 인도 ID- 이행 서버(16)에서 할당되고 견적 인도 품목 ID와 동일할 수 있음; (2) 수락 품목 인도에 대한 수락 수량; (3) 계약 선적일; (4) 고객 인도일; (5) 계약 로트-수락 품목 인도와 관련된 로트 식별자; 및 (6) 계약 속성- 수락 품목 인도에 대한 카테고리/속성 조합의 목록.
수락 프로세스(Process Acceptance)[이행 서버]
일 실시예에서, 수락(50)은 수락, 거절, 취소 또는 큐에 저장된 때에 각 계약 품목의 상태를 지정하는 객체이다. 이행 서버(16)는 대응하는 부품 계약(44)에 대한 상태를 나타내고, 품목 기준에 따라 거절된 것에서 수락할 것을 골라내며, 그런 다음 LFM(22)에 제출하기 위한 부품 수락(52)을 생성한다. 또한 이행 서버(16)는 부품 ATP 요청(32)의 상태를 적절히 갱신할 수 있다.
부품 수락 프로세스(Process Component Acceptances)[LFM]
LFM(22)은 이행 서버(16)로부터 부품 수락을 수신한 경우에 ATP 서버(14) 및 연관된 설계 엔진에 적합한 구문(syntax)으로 수락 트랜잭션을 발생시키고 이를 실행한다. 이 트랜잭션은 현존하는 계약(46)에 대한 정식 수락(formal acceptance)을 생성하는 것을 제외하고는 원래의 부품 견적 확인(42)과 유사하다. LFM(22)은 ATP 서버(14)로부터의 확인 응답을 기록하고 네트워크(18)를 이용하여 이를 이행 서버(16)에 반환한다.
부품 수락 확인 프로세스(Process Component Acceptance Confirmations)[이행 서버]
일단 이행 서버(16)는 부품 수락(52)을 처리하여 LFM(22)으로 전송하였으면, 부품 수락 확인(54) 결과의 완료를 감시한다. 일 실시예에서 수락 확인(56)은 각각의 부품 수락(52)이 하나 이상의 부품 수락 확인(54)을 수신한 경우 완료로 간주된다. 이행 서버(16)가 모든 부품 수락 확인(54)을 수신하여 수락 확인(56)이 완료된 경우, 이행 서버(16)는 모든 유효한 부품 수락 확인(54)을 포함하는 최종 수락 확인(56)을 네트워크(18)를 이용하여 클라이언트(12)로 전송한다.
ATP 요청 변경 작업흐름(ATP Request Change Workflow)
이 작업흐름에서, 클라이언트(12)는 활성 상태인 ATP 요청(30)을 질의하고, ATP 요청(30)의 일부 또는 전부를 변경하며, 이행 서버(16)에 ATP 요청(30)을 다시 제출한다. 그러면 이행 서버(16)는 변경된 ATP 요청(30)을 LFM(22)의 전체 분산 네트워크에 중개하고, 모든 미확인 응답(non-confirm)을 관리한다. 예를 들어 클라이언트(12)는 ATP 요청(30)과 관련한 계약된 수량이나 인도일을 변경할 목적으로 주문의 전부 또는 일부에 대해 재견적을 요청할 수 있다. 또한 클라이언트(12)는 활성 상태인 ATP 요청을 질의한 다음, 그 ATP 요청(30)을 취소하며, 이 경우에 이행 서버(16)는 이 취소를 ATP 요청(30) 부분을 처리하는 각 LFM(22)에 전달하여야 한다. 일 실시예에서, 취소는 ATP 요청(30)을 적절한 LFM(22) 및 이행 서버(16)를 포함한 데이터가 저장된 각 위치에서 실제로 삭제한다.
ATP 요청 변경 개시(Initiate ATP Request Changes)[클라이언트]
일단 클라이언트(12)에서 문의를 통해 ATP 요청(30)이 디스플레이되었으면, 사용자는 "요청 편집(edit request)" 모드(mode)로 들어갈 수 있다. 이 모드에서, 사용자는 소정의 적당한 방식으로 예를 들어, 요청 품목의 추가 또는 삭제, 요청된 수량 및 날짜의 변경 또는 관련된 거래 제약조건의 조정 등의 요청을 변경할 수 있다. 그리고 나서, 클라이언트(12) 또는 사용자는 변경된 ATP 요청(30)을 다시 제출하거나 또는 변경된 ATP 요청(30)을 다음에 다시 제출(재견적)할 목적으로 큐에 저장한다. 일 실시예에서, ATP 요청(30)이 완전하게 이행되었다면, 변경은 이루어질 수 없다. ATP 요청(30)이 불완전하게 이행되었다면, 아직 미결정 상태(pending)인 요청 품목만 변경될 수 있다.
ATP 요청 변경 프로세스(Process ATP Request Changes)[이행 서버]
이행 서버(16)는 다시 제출된 ATP 요청(30)을 평가하고, 변경이 요청 구성의 어떤 부분(즉, 요청, 요청 품목, 또는 요청 품목 인도)에서 이루어졌는지를 판단한다. 변경된 ATP 요청(30)의 부분에 대해, 이행 서버(16)는 현존하는 부품 ATP 요청(32)을 적절히 수정한다. 이것은 명기된 거래 제약조건뿐만 아니라 모든 소싱, 대체나 대용 또는 다른 선택물에 대한 재평가를 포함할 수 있다. 또한 변경은 추가 또는 개별 요청 품목을 포함할 수 있다. 일단 이행 서버(16)가 이러한 수정을 완료하였으면, 부품 ATP 요청(32)의 결과는 LFM(22)에 제공하기 위해 다시 네트워크(20) 상으로 전송된다. 각 부품 ATP 요청(32)의 상태는 "견적중" 또는 "취소중"으로 적절히 설정될 수 있다.
부품 ATP 요청 프로세스(Process Component ATP Requests)[LFM]
LFM(22)이 변경된 부품 ATP 요청(32)을 이행 서버(16)로부터 수신한 경우, LFM(22)은 ATP 서버(14) 및 연관된 설계 엔진에 적합한 구문으로 요청 트랜잭션을 생성시키고 실행한다. 이 시점에서, 변경된 구성 ATP 요청(32)은 그것이 새로운 부품 ATP 요청(32)인 것처럼 ATP 서버(14)에서 처리된다. 모든 부품 ATP 요청 취소는 ATP 서버(14)에서 삭제됨으로써 처리될 수 있다.
LFM(22)은 변경된 부품 ATP 요청(32)에 명기된 거래 제약조건에 따라 ATP 서버(14)로부터의 응답을 평가한다. 이 단계에서 LFM(22)의 처리 요구조건은 새로운 부품 ATP 요청(32)에 관련된 요구조건과 동일할 수 있다. 취소하는 동안, LFM(22)는 모든 국부적(locally)으로 유지되는 부품 ATP 요청(32) 또는 부품 견적(34)의 상태를 "취소"로 갱신할 수 있다. LFM(22)은 ATP 서버(14)로부터 부품 견적 응답을 수신하고, 새로운 부품 견적(34)의 형태로 이행 서버(16)로 제약조건에 순응한다는 응답(constraint-compliant responses)을 전송한다. 위에서 설명한 방식으로 설명 또는 다른 실패 통지가 생성될 수 있다. 또한 필요하다면, 취소 확인이 생성되어 이행 서버(16)에 전송될 수 있다.
부품 견적 프로세스(Process Component Quotations)[이행 서버]
이행 서버(6)가 변경된 부품 ATP 요청(32)을 처리하여 LFM에 전송하였을 경우, 이행 서버(6)는 부품 견적(34) 결과의 완료를 감시한다. 일 실시예에서, 견적(36)은 각각의 원래의 변경된 부품 ATP 요청(30)이 경우에 따라서는 하나 이상의 부품 견적(34), 실패 통지 또는 취소 확인을 수신하였을 때 완료된 것으로 간주한다. 이행 서버(16)는 모든 ATP 요청(30) 및 이행 서버(16)에 유지되는 견적(36)의 상태를 LFM(22)으로부터 수신된 모든 취소 확인에 기초하여 갱신할 수있다.
일단 부품 견적(34)이 수신되어 견적(36)을 완료한 것으로 간주되면, 이행 서버(16)는 원래의 변경된 ATP 요청(30)에 명기된 거래 제약조건에 따라 전체 견적(36)을 재평가한다. 프로세싱은 새로운 ATP 요청(30)에 대한 견적(36)의 그것과 동일하다. 견적 가격책정은 출발선(scratch)이나 새롭게 견적되는 품목에 대한 현존하는 확립된 가격의 견지에서 다시 계산된다. 이행 서버(16)가 명기된 ATP 요구 제약조건에 관련하여 견적(36)을 평가하였을 경우, 통합된 견적(36)이 클라이언트(12)에게 제공된다. 이 프로세스는 원래의 견적(36)이 이미 존재하기 때문에 이행 서버(16)가 변경된 ATP 요청(30)과 관련된 견적(36)에 대한 부분만을 갱신하는 것을 제외하고는 새로운 견적(36)의 프로세스와 유사하다. 실패 통지 및 취소 확인이 적절히 생성되어 클라이언트(12)에 전송될 수 있다. 다음의 사용자 확인 프로세싱은 순수 변경 기준(net change basis)따라 이루어질 수 있고, 견적 확인 및 계약 수락 작업흐름과 관련하여 위에서 설명한 프로세싱에 반영될 수 있다.
재견적 작업흐름(Re-Quote Workflow)
일 실시예에서, 클라이언트(12) 또는 연관된 사용자는 전체 또는 부분적인 주문의 취소나 이행 전에 임의의 시점에서 현존하는 ATP 요청(30)에 대해 재견적을 요청할 수 있다. 이러한 능력은 현존하는 계약(46)에 조금도 영향을 미치지는 않지만 간단히 새로운 견적(36)을 생성한다. 클라이언트(12) 또는 연관된 사용자는 현존하는 계약(46)을 제거하기 위하여 새로운 견적(36)을 수락해야만 한다. 따라서, 모든 프로세싱은 데이터 객체의 취급을 제외하고 최초의 ATP 요청(30)과 실적적으로 동일하다. 클라이언트(12) 또는 연관된 사용자는 이 프로세싱을 개시하기 위해 원래의 ATP 요청(30)에 대해 질의한다. 일단 ATP 요청(30)이 문의를 통해 디스플레이되었으면, 사용자는 적절한 재견적 기능을 선택하고 클라이언트(12)는 재견적 명령을 실행한다.
큐 ATP 요청 작업흐름(Queue ATP Request Workflow)
이행 서버(16)는 사용자, 고객, 또는 다른 프로파일(profile), 클라이언트(12)나 연관된 사용자로부터 수신한 정보, 또는 시스템 관리자(administrator)나 기능(function)에 따라 구성할 수 있는 요청의 지능적인 큐잉(intelligent queuing)을 지원할 수 있다. 큐 요청 파라메터(request queue parameter)는 큐잉이 발생하는 조건, 큐잉의 지속 기간(duration) 및 요청이 다시 제출되는 빈도에 대한 조건을 지정할 수 있다. 모든 변경은 전부 LFM(22)에 분산되고 ATP 서버(14)는 만족할만한 계약을 얻기 위한 큐잉 요청을 허용할 수 있기 때문에, 이러한 변경은 하나 이상의 이행 서버(16)에 전송되어야 한다. 각 이행 서버(16)는 자신의 큐에 저장된 요청을 변경의 관점에서, 어쩌면 적절한 견적의 개시 또는 계약 작업흐름의 관점에서 재고할 수 있다. ATP 요청(30)의 큐잉은 미합중국 특허 출원 제08/491,167호 및 제08/802,434호에 더욱 완전하게 설명되어 있다.
ATP 요청 큐 개시(Initiate ATP Request Queue)[클라이언트]
일 실시예에서, 클라이언트(12) 또는 연관된 사용자는 전체 또는 부분적인 주문 취소나 이행 전에 임의의 시점에서 현존하는 ATP 요청(30)을 큐에 저장할 수 있다. 큐에 저장된 ATP 요청(30)은 견적 결과를 향상시키는 것을 목적으로 재견적을 위해 주기적으로 제출된다. 앞서 설명한 재견적 트랜잭션과 유사하게, 큐잉 프로세스는 현존하는 계약(46)에 조금도 영향을 미치지는 않지만 간단히 새로운 견적(36)을 생성한다. 클라이언트(12) 또는 연관된 사용자는 초기 ATP 요청(30)의 불만족스런 결과가 있은 다음에 또는 현존하는 ATP 요청(30)에 대한 질의가 있은다음에 큐 프로세싱을 개시하기 위하여 큐 기능을 실행할 수 있다. 큐잉 동작(queuing behavior)은 재시도 간격(re-try intervals), 최대 시도 회수 등에 연관된 지정된 파라메터에 따라 제한될 수 있다.
ATP 요청 큐 프로세스(Process ATP Request Queue)[이행 서버]
이행 서버(16)는 모든 요청 품목이 큐에 저장되었음을 나타내는 확인으로서 요청 큐 명령(instruction)을 수신한다. 이 확인에 근거하여 이행 서버(16)는 각 요청 품목의 상태를 "큐에 저장됨(queued)"으로 갱신한다. 또한 ATP 요청(30)의 프로세싱은, 그러한 프로세싱에 대한 큐잉 파라메터가 충족되었을 때까지 잠시 보류된다. 지정된 재시도 간격에 기초하든 기초하지 않든, 이행 서버(16)는 견적을 위해 이행 서버(16)는 주기적으로 큐에 저장된 부품 ATP 요청(32)을 LFM(22)에 다시 제출할 수 있다. 이 이점에서, 이 프로세싱은 앞서 설명한 재견적 작업흐름 프로세스의 그것과 동일하다.
부품 계약 변경 작업흐름(Component Promise Change Workflow)
도 5는 본 발명에 따른 부품 계약 변경 작업흐름을 도시한다. 이러한 또는 유사한 작업흐름은 임의의 적당한현존하는 수량, 수락, 계약, 견적, 요청 또는 공급의 수정(modification)을 처리하는 데 사용될 수 있다. 공급을 지원하는 주문 잔고로서 확보된 부품 ATP 요청(32)은 시간에 따라 변동하는 것이 보통이다. 어떤 형태의 변경은 드물지만 다른 형태의 변경은 흔하므로 효율적으로 처리되어야 한다. 일례로서, 설계된 공급량(supply)은 보통 적어도 주간으로, 종종 일간으로, 가끔은 더욱 빈번하게 정기적인 기준에 따라 종종 변경한다. 게다가, 여러 제품또는 판매자에 대한 공급량 할당은 출원되어 계류중인 미합중국 특허 출원 번호 제08/491,167호 및 제08/802,434호에 설명되어 있는 바와 같이, 일반적으로 적어도 빈번하다고 할만큼 변경한다. 두 경우 모두에서, 분산 시스템(10) 내의 영향을 받는 모든 요소들은 통지되어야 하고, 임의의 진행중인 견적(36) 또는 계약(46)은 조정되거나 낡은 것(stale)으로 표시될 필요가 있다.
생산 계획과 스케줄에 있어서의 변경의 영향력은 흐름에 따라 LFM(2)에서 부품 ATP 요청(32)으로 전파되기 쉬워, 하나 이상의 현존하는 매매 계약이 무효화 되도록 한다. 최종 결과는, 하나 이상의 부품 ATP 요청(32)이 나중에 설계 범위 내에서 다시 스케줄링 되거나 간단히 생략되는(shorted) 것일 수 있다. 일 실시예에서, LFM(22)는 이러한 사건(events)을 식별하고, 이에 따라 이행 서버(16)와 통신하기 위하여 부품 ATP 요청(32)의 상태를 감시한다. 일례로서, ATP 서버(16)는 주문 잔고로서 확보된 부품 ATP 요청(32)에 영향을 미치는 공급 변화를 LFM(22)에 "알려도(published)" 되고, 그럼 다음 LFM(22)가 이행 서버(16)에 통지해도 되며, 이행 서버(16)는 수정된 부품 요청 상태와 실행(act)을, 예를 들어 클라이언트(12)의 상태를 통지하고 하나 이상의 옵션을 클라이언트(12)에 제공함으로써 평가해도 된다. 마찬가지로, 이행 서버(16)에서 이루어진 변경은, 영향을 받는 LFM(22)이 공급 예약을 적절히 조절할 수 있도록 영향을 받는 LFM(22)에 전송될 필요가 있다. 또한, 이상에서 설명한 각각의 작업흐름은 작업중이었던 시스템(10)의 ATP 데이터 구성요소(data components)들이 그러한 변경에 의해 무효화되는 경우를 처리하기 위하여 하나 이상의 대안 작업흐름을 지원할 수 있다.
ATP 서버 변경 프로세스(Process ATP Server Changes)[LFM]
일 실시예에서, 시스템(10)은LFM(22)과 ATP 서버(14) 사이의 인터페이스 프로토콜(interface protocol)을 제공하여, 연관된 설계 엔진에서 부품 ATP 요청(32)의 계약 특성에 영향을 미치는 설계 변경이 ATP 서버(14) 내에서 사전 행동으로(proactively) 식별되고, 평가를 위해 LFM(22)으로 전송되도록 한다. 이 평가 프로세싱은 최초의 부품 계약 응답의 그것과 동일하다; 즉, LFM(22)은 원래의 ATP 요청(30)에 명기된 제약조건에 따라 변경된 부품 계약 응답을 평가한다. ATP 서버(14)에서의 수정된 계약은 고객과 공급자 사이의 매매 계약을 변경시킬 수 없다. 때문에 일 실시예에서 계약(46)과 수락(50)은 별개의 객체이고, 계약(36)의 변경은 수락(50)을 변경시키지 않으며, 이것은 일반적으로 고객과 공급자 사이의 구속력을 갖는 상사 매매 계약(business commitment)으로 나타낸다. 스케줄과 다른 변경들은 원래의 매매 계약이 유지될 수 있도록 협상될 수 있고 해결될 수 있다. 그러나, 구속력을 갖는 상사 매매 계약은 클라이언트(12) 또는 연관된 사용자가 수정된 계약(62)을 수락하여 새로운 수락(64)이 생성될 때까지 변경되지 않는다.
설계 변경(planning change)이 부품 계약(44)의 유효성을 영향을 미쳤든 그렇지 않았든 LFM(22)은 변경을 위한 설계 변경 통지(60)를 생성하고, 또한 존재하는 모든 실패 상태를 기록할 수 있다. 설계 변경 통지(60)는 적당한 포맷으로 생성되어 네트워크(20)를 이용하여 이행 서버(16)로 전송된다. 설계 변경 통지(60)는 이행 서버(16)에게 수정된 계약(62)을 생성하여 클라이언트(12)에 전송할 것을촉구할 수 있다. 이 대신에 또는 이에 추가하여, 이행 서버(16)는 설계 변경 통지(60)를 평가하고, 위에서 설명한 변경된 부품 ATP 요청(32)과 본질적으로 동일한 방식으로 LFM(22)에 전송되어 처리될 하나 이상의 수정된 부품 ATP 요청(66)을 생성할 수 있다. 이행 서버(16)는 클라이언트(12)와 연관된 고객 및 사용자의 요구에 따른 모든 적당한 방식으로 설계 변경 통지(60)를 실행할 수 있다.
LFM 변경 프로세스(Process LFM Changes)[이행 서버]
이행 서버(16)는 부품 계약 변경과 같은 LFM 개시 사건(LFM-initiated events)을 감시하고 응답한다. ATP 서버(14)와 연관된 설계 엔진 내에서의 부품 계약 변경은 원래의 계약(46)의 무결성(integrity)에 실질적으로 강한 영향을 주었을 수 있다. 그러므로, 일 실시예에서 이행 서버(16)는 원래의 ATP 요청(30)에 명기된 제약조건에 따라 계약(46)을 재평가한다. 예를 들어, ATP 요청(30)에 관련된 부족 비율(short proportional) 속성의 값에 따라, 이행 서버(16)는 모든 요청 품목의 계약을 비례적으로 조정할 수 있고, 부족한 다른 요청 품목의 할당을 해제할 수 있다. 이러한 실패는 비록 고객이 그러한 제품들을 결국 수락하지 않을 것이지만, 제품을 고객에게 묶어둔 채로 두어도 된다. 이행 서버(16)는 ATP 요청(30)의 조정 또는 실패 전에 하나 이상의 대체 공급자를 찾으려고 시도하거나, 클라이언트(12) 또는 연관된 사용자가 검토하고 해결하도록 적당한 문제 통지를 단순히 생성할 수 있다.
이행 서버(16)는 LFM 개시 변경을 하는 경우, 어쩌면 변경의 본질(nature)에 기초한 모든 가격책정을 위한 계산이 필요한지를 결정하는 경우에, 새로운가격(re-price)의 계약(46)을 임의로 하는 능력을 제공할 수 있다. 예를 들어, ATP 요청(30)에 대한 선적일의 변경은 다시 가격책정을 요구할 수 없고, 수량의 변경은 계약 가격이 무효화시킬 수 있다. 이 대신에 또는 이에 추가하여, 이행 서버(16)는 LFM 개시 변경에 기초하여 인도 날짜를 다시 계산하고, 어쩌면 변경의 특성에 기초하여 모든 인도에 대한 계산(delivery calculations)이 필요한지를 결정하는 능력을 제공할 수 있다.
이행 서버(16)가 ATP 요청(30)에 명기된 제약조건에 관련된 소정의 변경된 부품 계약((44)을 평가하였을 경우, 이행 서버(16)는 수정된 계약(62)을 생성하여 클라이언트(12)로 전송한다. 이 프로세싱은 원래의 계약(36)이 이미 존재하고 이행 서버(16)가 수정된 계약(62)을 생성함에 있어 ATP 요청 변경과 관련된 계약(46) 부분만을 갱신하는 것을 제외하고는 계약 확인 프로세싱과 동일하다. 실패 통지는 적절히 생성될 수 있다. 이 단계에서, 클라이언트(12) 또는 연관된 사용자는 단순히 변경된 채로 존속하기를 원할 수 있으며, 수락(62)을 생성시켜 이행 서버(16)로 전송하거나 재견적, 변경 또는 취소 작업흐름으로 계속 진행한다.
ATP 요청 취소 작업흐름(ATP Request Cancellation Workflow)
ATP 요청 취소 개시(Initiate ATP Request Cancellation)[클라이언트]
일 실시예에서, 클라이언트(12) 또는 연관된 사용자는 예를 들어 명기된 시간 간격의 범위를 넘는 것과 같이 공급자의 거래 제약조건이 명백히 취소를 배제하지만 않으면, ATP 요청(30)을 ATP 요청(30)의 라이프 사이클 동안의 임의의 시점에서 취소할 수 있다. 그 결과로서, ATP 요청(30)은 최초의 생성중에, 견적 프로세싱중에, 수락 후에 그리고 불완전한 이행 후에 조차도 취소될 수 있다. 취소의 의미는 ATP 요청(30)을 영구히 비활동 상태(inactive) 상태로 만드는 것이다. 클라이언트(12) 또는 연관된 사용자는 이 프로세싱을 개시하기 위하여 ATP 요청(30)에 대해 질의할 수 있다. 일단 ATP 요청(30)이 문의를 통해 클라이언트(12)에서 디스플레이되었으면, 사용자는 클라이언트(12)에게 취소 명령을 실행하도록 하는 취소 기능을 선택할 수 있다.
ATP 요청 취소 프로세스(Process ATP Request Cancellation)[이행 서버]
이행 서버(16)는 모든 요청 품목이 취소되었음을 나타내는 형태의 취소 요청을 클라이언트(12)로부터 수신한다. 다음에, 이행 서버(16)는 수신된 취소 요청에 취소 제약이 있는 어떤 제품이나 공급자가 존재하는지를 판단한다. 만약 있다면, 실패 통지가 즉각적으로 생성되어 네트워크(18)를 이용하여 클라이언트(12)로 전송된다. 그런 후, 이행 서버(16)는 취소 요청의 유효성을 판단하고, 각 요청 품목의 상태를 "취소"로 갱신한다. 그리고 나서 이행 서버(16)는 적절한 LFM(22)에서의 프로세싱을 위하여 부품 요청 취소의 결과를 네트워크(20) 상으로 전송한다.
부품 ATP 요청 취소 프로세스(Process Component ATP Request Cancellations)[LFM]
LFM(22)이 이행 서버(16)로부터 부품 요청 취소를 수신한 경우, LFM(22)은 ATP 서버(14) 및 연관된 설계 엔진에 적합한 구문으로 취소 트랜잭션을 생성하고 실행한다. 이 트랜잭션은 십중팔구 ATP 요청의 삭제이다. ATP 서버(14)가 취소 확인으로 LFM(22)에 응답하는 경우, LFM(22)는 국부적으로 유지되는 소정의 부품ATP 요청, 부품 견적 및 부품 계약의 상태를 갱신한다. LFM(22)은 부품 취소 확인을 생성하여 네트워크(20)를 이용하여 이행 서버(16)에 전송한다.
부품 확인 프로세서(Process Component Confirmations)[이행 서버]
이행 서버(16)가 부품 요청 취소를 처리하여 LFM(22)로 전송하였을 경우, 이행 서버(16)는 부품 취소 확인 결과의 완료를 감시한다. 일 실시예에서, 각 부품 요청 취소가 부품 취소 환인을 수신하였을 경우에 취소 확인이 완료한 것으로 간주된다. 이행 서버(16)는 이행 서버(16)에서 유지되는 소정의 ATP 요청(30), 견적(36) 및 계약(46)에 있어서 취소를 기록할 수 있다. ATP 요청의 라이프 사이클을 종결하는 최종 취소 확인이 생성되어 네트워크(18)를 이용하여 클라이언트(12)로 전송된다.
이행 확인 작업흐름(Fulfillment Confirmations Workflow)
부품 이행 통지 프로세스(Process Component Fulfillment Notifications) [LFM]
일 실시예에서, 시스템(10)은 LFM(22)과 ATP 서버(14) 사이의 인터페이스 프로토콜을 제공하여, 연관된 설계 엔진에서의 선적 통지가 ATP 서버(14)에서 사전 행동으로(proactively) 식별되고 LFM(22)으로 전송되도록 한다. LFM(22)은 네트워크(20)를 이용하여 이행 서버(16)로 부품 이행 결과의 통지를 전송하기 전에 그 이행을 반영하기 위하여 국부적으로 유지되는 부품 ATP 요청(32) 및 부품 계약(44)의 그 상태를 갱신할 수 있다.
이행 통지 프로세스(Process Fulfillment Notifications)[이행 서버]
일단 수락(50)이 적절하게 처리되었으면, 이행 서버(16)는 LFM(22)에서의 부품 이행 통지를 감시한다. ATP 요청(30)은 각 부품 ATP 요청(32)이 부품 이행 통지를 수신하였을 경우에 이행된 것으로 간주된다. 통합된 이행 통지가 생성되어 네트워크(18)를 이용하여 그 요청을 한 클라이언트(12)에게 전송된다. 부품 ATP 요청(32)이 이행되었을 경우, 이행 서버(16)는 또한 대응하는 선적 확인을 감시한다. ATP 요청(30)이 완전히 선적되었을 경우, ATP 요청(30)의 상태는 갱신되고, 이행 서버(16)는 그 요청을 한 클라이언트(12)에게 통지한다. 이행 서버(16)는 이행된 ATP 요청(30)을 위한 기록 용량(archive capabilities)을 제공할 수 있으며, 이것은 클라이언트(12)에게 ATP 요청(30)이 기록된 때 및 유지되는 요청 이력(request history)의 기간(priode) 수 등과 같은 기록 파라메터들의 지정을 허용하도록 구성할 수 있다. 기록들은, 이행 서버(16)에서 LMF(22)에 연관련 하나 이상의 위치(locations)나 소정의 다른 적당한 시스템(10)의 내부 또는 외부 위치에서 유지될 수 있다.

Claims (76)

  1. ATP(available-to-promise) 데이터를 자동으로 관리하기 위한 시스템에 있어서,
    클라이언트 인터페이스(client interface);
    ATP 서버 인터페이스(ATP server interface); 및
    이행 서버(fulfillment server)
    를 포함하고,
    상기 이행 서버는,
    상기 클라이언트 인터페이스를 이용하여, 원하는 제품(product)에 각각 대응하는 복수의 요청 품목(line-item)들을 포함하는 제1 ATP 요청(request)을 수신하고,
    상기 요청 품목에 기초하여 하나 이상의 부품 ATP 요청을 생성하고,
    상기 ATP 서버 인터페이스를 이용하여, 상기 복수의 ATP 서버들 중 적어도 하나로 부품 ATP 요청을 전송하고,
    상기 ATP 서버 인터페이스를 이용하여, 각각 부품 ATP 요청에 대응하고 하나 이상의 원하는 대응 제품에 대한 제품 가용성 정보(product availability information)를 포함하는 복수의 부품 견적들을 상기 ATP 서버로부터 수신하고,
    상기 부품 견적에 의해 제공된 제품 가용성 정보에 따라서 정해진 견적을 생성하며,
    상기 클라이언트 인터페이스를 이용하여 상기 견적을 전송할 수 있는
    ATP 데이터 자동 관리 시스템.
  2. 제1항에 있어서,
    상기 ATP 요청은 하나 이상의 거래 제약조건(business constraint)을 명기하고,
    상기 이행 서버는 견적을 생성할 때 상기 거래 제약조건에 따라서 부품 견적을 평가하는 것을 추가로 할 수 있는 ATP 데이터 자동 관리 시스템.
  3. 제2항에 있어서,
    상기 거래 제약조건 중 적어도 몇몇은 고객 프로파일(customer profile)에 기초하는 ATP 데이터 자동 관리 시스템.
  4. 제1항에 있어서,
    상기 이행 서버는 상기 견적을 생성할 때 공급자-명기 거래 제약조건(supplier-specified business constraint)에 따라 부품 견적을 평가하는 것을 추가로 할 수 있는 ATP 데이터 자동 관리 시스템.
  5. 제1항에 있어서,
    상기 ATP 서버 각각이 자신과 연관된 설계 엔진(planning engine)에서 부품ATP 요청의 처리를 관리하는 로컬 이행 관리자(local fulfillment manager, LFM)와 연관된 ATP 데이터 자동 관리 시스템.
  6. 제1항에 있어서,
    상기 이행 서버는 제1 클라이언트로부터 상기 제1 ATP 요청을 수신하고, 상기 제1 ATP 요청과 동시에 제2 클라이언트로부터 제2 ATP 요청을 수신하는 ATP 데이터 자동 관리 시스템.
  7. 제1항에 있어서,
    상기 이행 서버는 상기 ATP 요청 내의 적어도 하나 이상의 거래 제약조건에 기초하여 목표(target) ATP 서버로 적어도 하나의 부품 ATP 요청을 전송하는 것을 추가로 할 수 있는 ATP 데이터 자동 관리 시스템.
  8. 제1항에 있어서,
    상기 이행 서버는,
    상기 클라이언트 인터페이스를 이용하여, 상기 견적 내의 상기 견적 품목들 중 적어도 몇몇에 대한 수락을 포함하는 견적 확인을 수신하고
    각 수락된 견적 품목에 대한 부품 견적 확인을 생성하고,
    상기 ATP 서브 인터페이스를 이용하여, 상기 ATP 서버로 부품 견적 확인 (component quotation confirmation)을 전송하고,
    상기 ATP 서버 인터페이스를 이용하여, 각각 부품 견적 확인에 대응하고 수락된 대응 제품에 대한 제품 가용성의 매매 계약(commitment)을 제시하는(representing) 복수의 부품 계약을 상기 ATP 서버로부터 수신하고,
    상기 부품 계약에 따라서 수락된 제품에 대한 제품 가용성의 매매 계약을 포함하는 계약을 생성하며,
    상기 클라이언트 인터페이스를 이용하여, 상기 계약을 전송하는
    것을 추가로 할 수 있고,
    상기 견적 항목 각각은 수락된 특정 제품에 대응하는
    ATP 데이터 자동 관리 시스템.
  9. 제8항에 있어서,
    상기 이행 서버는 상기 계약을 생성할 때 고객용으로 작성된(profiled) 거래 제약조건에 따라서 상기 부품 계약을 평가하는 것을 추가로 할 수 있는 ATP 데이터 자동 관리 시스템.
  10. 제8항에 있어서,
    상기 이행 서버는 상기 클라이언트 인터페이스를 이용하여 계약 수락을 수신하고, 상기 ATP 요청의 이행을 위하여 상기 ATP 서버로 상기 계약 수락을 전송하는 것을 추가로 할 수 있는 ATP 데이터 자동 관리 시스템.
  11. 분산된 공급망 설계 환경에서 동작하는 이행 서버에 있어서,
    원하는 제품에 각각 대응하는 복수의 요청 품목들을 포함하는 적어도 하나의 ATP(available-to-promise)를 클라이언트로부터 수신하고,
    상기 각 요청 품목에 대한 부품 ATP 요청을 생성하며,
    견적에 대한 복수의 로컬 이행 관리자(local fulfillment manager, LFM)들에게 부품 ATP 요청을 전송하고,
    상기 LFM 각각은 설계 엔진과 연관된
    이행 서버.
  12. 제11항에 있어서,
    상기 ATP 요청은 하나 이상의 거래 제약조건을 명기하고,
    상기 거래 제약조건에 따라서 상기 부품 ATP 요청을 생성하는 것을 추가로 할 수 있는 이행 서버.
  13. 제12항에 있어서,
    상기 거래 제약조건들 중 적어도 몇몇은 고객 프로파일에 기초하는 이행 서버.
  14. 제11항에 있어서,
    상기 ATP 요청 내의 하나 이상의 거래 제약조건에 기초하여 목표 LFM으로 적어도 하나의 부품 ATP 요청을 전송하는 것을 추가로 할 수 있는 이행 서버.
  15. 제11항에 있어서,
    각각 부품 ATP 요청에 대응하고 원하는 대응 제품에 대한 제품 가용성의 매매 계약을 제시하는 복수의 부품 계약을 상기 LFM으로부터 수신하고,
    상기 부품 계약에 따라서 원하는 제품 모두에 대한 제품 가용성의 매매 계약을 포함하는 계약을 생성하고,
    제1 클라이언트로 상기 계약을 전송하는
    것을 추가로 할 수 있는 이행 서버.
  16. 제15항에 있어서,
    상기 계약을 생성할 때 고객용으로 작성된 거래 제약조건에 따라서 부품 계약을 평가하는 것을 추가로 할 수 있는 이행 서버.
  17. 연관된 ATP(available-to-promise) 서버를 구비하고 다른 로컬 이행 관리자(local fulfillment manager, LFM)을 포함하는 분산된 공급망 환경에서 동작하는 로컬 이행 관리자에 있어서,
    이행 서버 인터페이스, 및
    ATP 서버 인터페이스
    를 포함하고,
    상기 LFM은,
    각각 원하는 제품에 대한 특정 ATP 요청 품목(line-item)에 대응하는 하나 이상의 부품 ATP 요청을 이행 서버로부터 수신하고,
    상기 연관된 ATP 서버를 이용하여 각 요청 품목에 대한 ATP 응답(response)을 결정하고 대응하는 상기 ATP 응답에 따라서 각 요청 품목에 대한 부품 견적을 생성하고,
    하나 이상의 다른 LFM으로부터의 다른 부품 견적과 통합(consolidation)하기 위하여 상기 이행 서버로 상기 부품 견적을 전송하는
    것을 추가로 할 수 있고,
    상기 부품 견적은 원하는 대응 제품에 대한 제품 가용성 정보를 포함하는
    로컬 이행 관리자.
  18. 제17항에 있어서,
    상기 부품 ATP 요청 각각은 하나 이상의 거래 제약조건을 명기하고,
    상기 LFM은 상기 부품 견적을 생성할 때 상기 거래 제약조건에 따라서 상기 ATP 응답을 평가하는 것을 추가로 할 수 있는 로컬 이행 관리자.
  19. 제18항에 있어서,
    상기 거래 제약조건들 중 적어도 몇몇은 고객 프로파일에 기초하는 로컬 이행 관리자.
  20. 제17항에 있어서,
    상기 LFM은 공급자-명기 거래 제약조건에 따라서 상기 부품 견적을 평가하는 것을 추가로 할 수 있는 로컬 이행 관리자.
  21. 제17항에 있어서,
    상기 LFM은 연관된 설계 엔진에서 상기 부품 ATP 요청의 처리를 관리하고, 상기 ATP 서버로부터 획득한 정보에 따라서 상기 ATP 응답의 일부(a portion)를 계산할 수 있고,
    상기 ATP 응답의 일부는 상기 ATP 서버의 용량(capability)과 이 ATP 서버와 연관된 설계 엔진에 의존하는
    로컬 이행 관리자.
  22. 제17항에 있어서,
    클라이언트에서 견적 품목으로서 수락한 각 부품 견적에 대한 부품 견적 확인을 이행 서버로부터 수신하고,
    상기 연관된 ATP 서버를 이용하여 수락된 각 견적 품목에 대한 계약 응답을 정하고,
    수락된 대응 제품에 대한 제품 이용성의 매매 계약을 제시하는, 수락된 각 견적 품목에 대한 부품 계약을 생성하고,
    하나 이상의 다른 LFM들로부터의 부품 계약과 통합(consolidation)하기 위하여 상기 이행 서버로 상기 부품 계약을 전송하는
    것을 추가로 할 수 있는 로컬 이행 관리자.
  23. 제22항에 있어서,
    상기 부품 계약을 생성할 때 고객용으로 작성된 거래 제약조건에 따라서 상기 계약 응답을 평가하는 것을 추가로 할 수 있는 로컬 이행 관리자.
  24. 제17항에 있어서,
    상기 부품 ATP 요청은 개개의(individual) 품목(item)에 대응하고,
    상기 LFM은 어떻게 이행 서버가 부품 견적들을 변화시킬 수 있는지에 관한 정보와 규칙들(rule)을 포함하는 상기 부품 견적들을 계산할 수 있는
    로컬 이행 관리자.
  25. 제17항에 있어서,
    상기 부품 ATP 요청은 개개의 품목에 대응하고,
    상기 LFM은 어떻게 이행 서버가 부품 계약들을 변화시킬 수 있는지에 관한 정보와 규칙들을 포함하는 상기 부품 견적들을 계산할 수 있는
    로컬 이행 관리자.
  26. 제17항에 있어서,
    상기 이행 서버로부터 부품 ATP 요청들의 시퀀스(sequence)를 수신하고,
    하나 이상의 최종 부품 견적을 계산하기 위하여 상기 LFM으로 목표가 정해진(targeted) 제1 부품 ATP 요청들을 처리하고,
    상기 시퀀스 내에 남아 있는 부품 ATP 요청과 함께, 상기 시퀀스 내의 하나 이상의 제2 부품 ATP 요청들에 의해 목표가 정해진 제2 LFM으로 최종 부품 견적을 전달하는(pass)
    것을 추가로 할 수 있고,
    상기 시퀀스 내의 하나 이상의 제1 부품 ATP 요청은 상기 LFM으로 목표가 정해지는
    로컬 이행 관리자.
  27. 제17항에 있어서,
    상기 이행 서버에 의해 역시 지원되는 판매자 계층(seller hierarchy)을 지원하고,
    상기 이행 서브에 의해 지원되는 제품의 서브셋(subset)을 지원하고,
    상기 제품의 서브셋에 대한 상기 판매자 계층 전체(throughout)의 할당량(allocation)에 기초하여 매(per) 제품 기준(basis)에 따라 부품 견적들 또는 부품 계약들을 계산할 수 있는
    로컬 이행 관리자.
  28. 제17항에 있어서,
    상기 이행 서버에 의해 지원된 관련 제품의 계층 내에 있는 제품들의 서브셋을 지원하고,
    상기 계층 전체(throughout)의 제품들의 상기 서브셋에 대한 할당량에 기초하여 부품 견적들 또는 부품 계약들을 계산할 수 있는
    로컬 이행 관리자.
  29. 제28항에 있어서,
    상기 LFM은 일반 제품(generic product)들에 대응하는 제2 LFM으로 부품 ATP 요청을 전송하여 제품류(generics of product)의 가용성을 계산하는 것을 추가로 할 수 있는 로컬 이행 관리자.
  30. 제17항에 있어서,
    상기 이행 서버에 의해 지원되는 판매자 계층 내의 판매자에 대응하고.
    대응하는 상기 판매자에 대한 공급의 할당량을 유지시키고,
    자신이 포함하고 있는(contain) 상기 할당량으로 가능한 모든 부품 견적들이나 부품 계약들을 계산하고,
    마치 상기 ATP 요청이 모든 상기 할당량들을 갖는 단일 시스템에 의해 견적되거나 계약된 것처럼, 각 제품에 대하여, 조합(combination)을 위하여 상기 이행서버로 상기 부품 견적들이나 부품 계약들을 전송할 수 있는
    로컬 이행 관리자.
  31. 제30항에 있어서,
    상기 LFM은 부 판매자(parent seller)에 대응하는 제2 LFM으로 부품 ATP 요청을 전송함으로써 대응하는 부 판매자의 가용성을 추가로 계산하는 것을 추가로 할 수 있는 로컬 이행 관리자.
  32. 제17항에 있어서,
    상기 LFM은 복수의 이행 서버로부터 부품 ATP 요청을 수락하고 상기 복수의 이행 서버로 부품 견적이나 부품 계약들을 전송하는
    것을 추가로 할 수 있는 로컬 이행 관리자.
  33. 제17항에 있어서,
    상기 LFM은 제품 계층의 세브셋을 지원하고 상기 계층 내의 제품에 대한 할당량에 기초하여 부품 견적이나 부품 계약들을 계산하는 것을 추가로 할 수 있는 로컬 이행 관리자.
  34. ATP(available-to-promise) 데이터를 자동으로 관리하기 위한 시스템에 있어서,
    클라이언트 인터페이스;
    로컬 이행 관리자(local fulfillment manager, LFM) 인터페이스; 및
    이행 서버
    를 포함하고,
    상기 이행 서버는,
    상기 클라이언트 인터페이스를 이용하여, 원하는 제품에 각각 대응하는 복수의 요청 품목을 포함하는 제1 ATP 요청을 수신하고,
    상기 요청 품목에 기초한 하나 이상의 부품 ATP 요청을 생성하고,
    상기 LFM 서버 인터페이스를 이용하여, 상기 복수의 LFM들 중 적어도 하나로 부품 ATP 요청을 전송하고,
    상기 LFM 인터페이스를 통해, 각각 부품 ATP 요청에 대응하고 하나 이상의 원하는 대응 제품에 대한 제품 가용성 정보를 포함하는 복수의 부품 견적들을 상기 LFM으로부터 수신하고,
    상기 부품 견적에 의해 제공된 제품 가용성 정보에 따라서 정해진 견적을 생성하며,
    상기 클라이언트 인터페이스를 이용하여 상기 견적을 전송할 수 있는
    ATP 데이터 자동 관리 시스템.
  35. 제34항에 있어서,
    상기 이행 서버는,
    개개의 품목에 대응하는 부품 ATP 요청들 및 어떻게 이행 서버가 어떻게 상기 부품 견적을 변화시킬 수 있는지에 관한 정보와 규칙들을 포함하는 LFM로부터 수신한 부품 견적을 계산하고,
    상기 정보와 규칙에 따라서 부품 견적을 변화시켜, 상기 부품 견적이 하나 이상의 거래 제약조건을 함께 만족시키는
    것을 할 수 있는 ATP 데이터 자동 관리 시스템.
  36. 제34항에 있어서,
    상기 이행 서버는,
    개개의 품목에 대한 부품 ATP 요청을 계산하고, 어떻게 상기 이행 서버가 부품 견적들을 변화시킬 수 있는지에 관한 정보와 규칙들을 포함하는 LFM으로부터 부품 계약들을 수신할 수 있고,
    상기 정보와 규칙에 따라서 상기 부품 계약들을 변화시켜, 상기 부품 계약들이 하나 이상의 거래 제약조건을 함께 만족시키고,
    LFM으로 다시(back) 변화된 상기 부품 계약을 전송시켜 상기 LFM이 공급 예약(supply reservation)을 조정하는 것을 추가로 할 수 있는
    ATP 데이터 자동 관리 시스템.
  37. 제34항에 있어서,
    상기 이행 서버는,
    상기 연관된 LFM을 통해 지원된 모든 품목(item)을 포함하는 부품 ATP 요청 및 상기 부품 ATP 요청의 품목(item)으로 신청하는(apply) 상기 ATP 요청에 따라서 모든 거래 제약조건을 계산하고,
    상기 거래 제약조건을 이행하는 부품 견적을 각 LFM으로부터 수신하고,
    상기 ATP 요청에 대응하는 상기 견적을 생성하도록 최종 다수 품목 부품 견적(multi-item component quotation)을 결합시킬 수 있는
    ATP 데이터 자동 관리 시스템.
  38. 제34항에 있어서,
    상기 이행 서버는,
    상기 연관된 LFM을 통해 지원된 모든 품목과 상기 부품 ATP 요청의 상기 품목으로 신청하는 상기 ATP 요청에 따라서 모든 거래 제약조건을 포함하는 부품 ATP 요청을 계산하고,
    상기 거래 제약조건을 이행하는 부품 계약을 각 LFM으로부터 수신하고,
    상기 ATP 요청에 대응하는 단일 계약을 생성하도록 최종 다수 품목 부품 견적을 결합시킬 수 있는
    ATP 데이터 자동 관리 시스템.
  39. 제34항에 있어서,
    상기 LFM들 중 적어도 몇몇은 동일한 제품에 대한 개별적인 할당량을 유지하고.
    상기 이행 서버는 상기 제품에 대한 부품 견적을 획득하기 위하여 복수의 LFM을 거쳐 견적 동작(quoting activity)을 분산하는 것을 추가로 할 수 있는
    ATP 데이터 자동 관리 시스템.
  40. 제34항에 있어서,
    상기 이행 서버는 또한 LFM으로서 동작할 수 있는 ATP 데이터 자동 관리 시스템.
  41. ATP(available-to-promise) 데이터를 자동으로 관리하기 위한 방법에 있어서,
    원하는 제품에 각각 대응하는 복수의 요청 품목(request line-item)을 포함하는 제1 ATP 요청을 수신하는 단계,
    상기 요청 품목에 따라서 하나 이상의 부품 ATP 요청을 생성하는 단계;
    ATP 서버 인터페이스를 이용하여, 복수의 ATP 서버들 중 적어도 하나로 부품 ATP 요청을 전송하는 단계;
    상기 ATP 서버 인터페이스를 이용하여, 각각 부품 ATP 요청에 대응하고 원하는 하나 이상의 대응 제품에 대한 제품 가용성 정보를 포함하는 복수의 부품 견적들을 ATP 서버로부터 수신하는 단계;
    상기 부품 견적에 의해 제공된 상기 제품 가용성 정보에 따라서 견적을 생성하는 단계; 및
    상기 견적을 전송하는 단계
    를 포함하는 ATP 데이터 자동 관리 방법.
  42. 제41항에 있어서,
    상기 견적을 생성할 때 하나 이상의 거래 제약조건에 따라서 상기 부품 견적을 평가하는 단계를 추가로 포함하고,
    상기 ATP 요청은 상기 거래 제약조건을 명기하는
    ATP 데이터 자동 관리 방법.
  43. 제42항에 있어서,
    상기 거래 제약조건들 중 적어도 몇몇은 고객 프로파일(customer profile)에 기초하는 ATP 데이터 자동 관리 방법.
  44. 제41항에 있어서,
    상기 견적을 생성할 때 적어도 하나의 공급자-명기 거래 제약조건에 따라서 상기 부품 견적을 평가하는 단계를 추가로 포함하는 ATP 데이터 자동 관리 방법.
  45. 제41항에 있어서,
    상기 ATP 서버 각각이 자신과 연관된 설계 엔진에서 부품 ATP 요청의 처리를관리하는 로컬 이행 관리자(local fulfillment manager, LFM)와 연관된 ATP 데이터 자동 관리 방법.
  46. 제41항에 있어서,
    상기 이행 서버는 제1 ATP 요청과 동시에, 제2 ATP 요청을 수신하는 단계를 추가로 포함하는 ATP 데이터 자동 관리 방법.
  47. 제41항에 있어서,
    적어도 하나의 부품 ATP 요청은 상기 ATP 내의 하나 이상의 거래 제약조건에 기초하여 목표로 정해진(targeted) LFM으로 전송되는 ATP 데이터 자동 관리 방법.
  48. 제41항에 있어서,
    견적 내의 적어도 몇몇 견적 품목의 수락을 포함하는 견적 확인을 수신하는 단계;
    각 수락된 견적 품목에 대한 부품 견적 확인을 생성하는 단계;
    상기 ATP 서브 인터페이스를 통해 상기 ATP 서버로 부품 견적 확인을 전송하는 단계;
    상기 ATP 서버 인터페이스를 이용하여, 각각 부품 견적 확인에 대응하고 수락된 대응 제품에 대한 제품 가용성의 매매 계약을 제시하는 복수의 부품 계약을 상기 ATP 서버로부터 수신하는 단계;
    상기 부품 계약에 따라 수락된 제품에 대한 제품 가용성의 매매 계약을 포함하는 계약을 생성하는 단계; 및
    상기 계약을 전송하는 단계
    를 추가로 포함하고,
    상기 견적 품목 각각은 수락된 특정 제품에 대응하는
    ATP 데이터 자동 관리 방법.
  49. 제8항에 있어서,
    상기 계약을 생성할 때 고객용으로 작성된 거래 제약조건에 따라서 부품 계약을 평가하는 단계를 추가로 포함하는 ATP 데이터 자동 관리 방법.
  50. 제48항에 있어서,
    계약 수락을 수신하는 단계; 및
    상기 ATP 요청의 이행을 위하여 상기 ATP 서버로 상기 계약 수락을 전송하는 단계를
    추가로 포함하는 ATP 데이터 자동 관리 방법.
  51. 분산된 공급망 설계 환경 내의 이행 서버에서 ATP(available-to-promise) 데이터를 관리하기 위한 방법에 있어서,
    원하는 제품에 각각 대응하는 복수의 요청 품목을 포함하는 적어도 하나의ATP 요청을 클라이언트로부터 수신하는 단계;,
    상기 요청 품목에 기초하여 하나 이상의 부품 ATP 요청을 생성하는 단계; 및
    견적에 해당하는 복수의 로컬 이행 관리자(LFM)로 부품 ATP 요청을 전송하는 단계
    를 포함하고,
    상기 LFM 각각은 설계 엔진과 연관된
    ATP 데이터 자동 관리 방법.
  52. 제51항에 있어서,
    상기 ATP 요청 내의 하나 이상의 거래 제약조건에 기초하여 목표로 정해진 LFM으로 적어도 하나의 부품 ATP 요청을 전송하는 단계; 및
    상기 견적을 생성할 때 거래 제약조건에 따라서 부품 견적을 평가하는 단계
    를 추가로 포함하고,
    상기 거래 제약조건은 고객 프로파일에 기초하는
    ATP 데이터 자동 관리 방법.
  53. 제51항에 있어서,
    각각 부품 ATP 요청에 대응하고 원하는 대응 제품에 대한 제품 가용성 정보를 제시하는 복수의 부품 견적을 상기 LFM으로부터 수신하는 단계;
    상기 부품 계약에 따라서 상기 원하는 제품에 대한 제품의 가용성의 매매 계약을 포함하는 계약을 생성하는 단계; 및
    상기 클라이언트로 상기 계약을 전송하는 단계
    를 추가로 포함하는 ATP 데이터 자동 관리 방법.
  54. ATP 데이터를 관리하기 위하여 로컬 이행 관리자(LFM)에서 동작하는 방법에 있어서,
    각각 원하는 제품에 대한 특정 ATP 요청 품목에 대응하는 하나 이상의 부품 ATP 요청을 이행 서버로부터 수신하는 단계;
    연관된 ATP 서버를 이용하여 각 요청 품목에 대한 ATP 응답을 계산하는 단계;
    상기 대응하는 ATP 응답에 따라서 각 요청 품목에 대한 하나 이상의 부품 견적을 생성하는 단계;
    상기 하나 이상의 다른 LFM으로부터의 다른 부품 견적과 통합(consolidation)하기 위하여 이행 서버로 상기 부품 견적을 전송하는 단계;
    를 포함하고,
    상기 부품 견적은 상기 원하는 대응 제품에 대한 제품 가용성 정보를 포함하는
    ATP 데이터를 관리하기 위한 로컬 이행 관리자 동작 방법.
  55. 제54항에 있어서,
    상기 부품 견적을 생성하도록 상기 ATP 요청에서 명기된 하나 이상의 거래 제약조건에 따라서 상기 ATP 응답을 평가하는(assessing) 단계를 추가로 포함하는 ATP 데이터를 관리하기 위한 로컬 이행 관리자 동작 방법.
  56. 제55항에 있어서,
    상기 거래 제약조건들 중 적어도 몇몇은 고객 프로파일에 기초하는 ATP 데이터를 관리하기 위한 로컬 이행 관리자 동작 방법.
  57. 제54항에 있어서,
    공급자-지정 거래 제약조건에 따라 상기 부품 견적을 생성하는 단계를 추가로 포함하는 ATP 데이터를 관리하기 위한 로컬 이행 관리자 동작 방법.
  58. 제54항에 있어서,
    상기 연관된 ATP 서버로부터 획득한 정보에 따라서 상기 ATP 응답의 일부를 계산하는 단계를 추가로 포함하고,
    상기 LFM은 상기 연관된 설계 엔진에서 상기 부품 ATP 요청의 처리를 관리하고,
    상기 ATP 응답의 일부는 상기 ATP 서버의 용량과 ATP 서버와 연관된 설계 엔진에 의존하는
    ATP 데이터를 관리하기 위한 로컬 이행 관리자 동작 방법.
  59. 제54항에 있어서,
    클라이언트에서 견적 품목으로서 수락한 각 부품 견적에 대한 부품 견적 확인을 이행 서버로부터 수신하는 단계;
    상기 연관된 ATP 서버를 이용하여 수락된 각 견적 품목에 대한 계약 응답을 결정하는 단계;
    상기 수락된 제품에 대한 제품 가용성의 매매 계약을 제시하는, 수락된 각 견적 품목에 대한 부품 계약을 생성하는 단계;
    하나 이상의 다른 LFM들로부터의 부품 계약과 조합(combination)을 위하여 이행 서버로 상기 부품 계약을 전송하는 단계
    를 추가로 포함하는 ATP 데이터를 관리하기 위한 로컬 이행 관리자 동작 방법.
  60. 제59항에 있어서,
    상기 부품 계약을 생성할 때, 고객용으로 작성된 거래 제약조건에 따라 상기 계약 응답을 평가하는 단계를 추가로 포함하는 ATP 데이터를 관리하기 위한 로컬 이행 관리자 동작 방법.
  61. 제54항에 있어서,
    상기 부품 ATP 요청은,
    개개의 품목에 대응하고,
    어떻게 이행 서버가 상기 부품 견적을 변화시킬 수 있는지에 관한 정보와 규칙들을 포함하는 부품 견적들을 계산하는 단계
    를 추가로 포함하는 ATP 데이터를 관리하기 위한 로컬 이행 관리자 동작 방법.
  62. 제54항에 있어서,
    상기 부품 ATP 요청은,
    개개의 품목에 대응하고,
    어떻게 이행 서버가 상기 부품 계약들을 변화시킬 수 있는지에 관한 정보와 규칙들을 포함하는 부품 계약들을 계산하는 단계
    를 추가로 포함하는 ATP 데이터를 관리하기 위한 로컬 이행 관리자 동작 방법.
  63. 제54항에 있어서,
    상기 이행 서버로부터 부품 ATP 요청들의 시퀀스를 수신하는 단계;
    하나 이상의 최종 부품 견적을 계산하기 위하여 LFM으로 목표가 정해진 제1 부품 ATP 요청을 처리하는 단계;
    상기 시퀀스 내에 남아있는 하나 이상의 부품 ATP 요청과 함께, 상기 시퀀스 내의 하나 이상의 제2 부품 ATP 요청에 의해 목표가 정해진 제2 LFM으로 최종 부품견적을 전달하는(pass) 단계
    를 추가로 포함하는
    상기 시퀀스 내의 하나 이상의 제1 부품 ATP 요청은 상기 LFM으로 목표가 정해져 있는
    ATP 데이터를 관리하기 위한 로컬 이행 관리자 동작 방법.
  64. 제54항에 있어서,
    상기 이행 서버에 의해 역시 지원되는 판매자 계층(seller hierarchy)을 지원하는 단계;
    상기 이행 서버에 의해 지원되는 제품의 서브셋(subset)을 지원하는 단계; 및
    상기 제품의 서브셋에 대한 상기 판매자 계층 전체(throughout)의 할당량(allocation)에 기초하여 매 제품 기준에 따라서 부품 견적들 또는 부품 계약들을 계산하는 단계
    를 추가로 포함하는 ATP 데이터를 관리하기 위한 로컬 이행 관리자 동작 방법.
  65. 제54항에 있어서,
    상기 이행 서버에 의해 지원된 관련 제품의 계층 내 제품들의 서브셋을 지원하는 단계;
    상기 계층 전체 제품들의 상기 서브셋에 대한 할당량에 기초하여 부품 견적들 또는 부품 계약들을 계산하는 단계
    를 추가로 포함하는 ATP 데이터를 관리하기 위한 로컬 이행 관리자 동작 방법.
  66. 제54항에 있어서,
    일반 제품(generic product)에 대응하는 제2 LFM으로 부품 ATP 요청을 전송하여 제품류(generics of a product)의 가용성을 계산하는 단계를 추가로 포함하는 ATP 데이터를 관리하기 위한 로컬 이행 관리자 동작 방법.
  67. 제54항에 있어서,
    상기 LFM은 상기 이행 서버에 의해 지원되는 판매자 계층 내의 판매자에 대응하고,
    상기 대응하는 판매자에 대한 지원의 할당량을 LFM에서 유지시키는 단계;
    상기 LFM이 포함하고 있는 상기 할당량으로 가능한 모든 부품 견적들이나 부품 계약들을 계산하는 단계; 및
    마치 상기 ATP 요청이 모든 상기 할당량들을 갖는 단일 시스템에 의해 견적되거나 계약된 것처럼, 각 제품에 대하여, 조합(combination)을 위하여 상기 이행 서버로 상기 부품 견적들이나 부품 계약들을 전송하는 단계
    를 추가로 포함하는 ATP 데이터를 관리하기 위한 로컬 이행 관리자 동작 방법.
  68. 제67항에 있어서,
    부 판매자에 대응하는 제2 LFM으로 부품 ATP 요청을 전송함으로써 대응하는 부 판매자의 가용성을 계산하는 단계를 추가로 포함하는 ATP 데이터를 관리하기 위한 로컬 이행 관리자 동작 방법.
  69. 제54항에 있어서,
    복수의 이행 서버로부터 부품 ATP 요청을 수락하는 단계;
    상기 복수의 이행 서버로 부품 견적이나 부품 계약들을 전송하는 단계
    를 추가로 포함하는 ATP 데이터를 관리하기 위한 로컬 이행 관리자 동작 방법.
  70. 제54항에 있어서,
    제품 계층의 세브셋을 LFM에서 지원하는 단계;
    상기 계층 내의 제품에 대한 할당량에 기초하여 부품 견적이나 부품 계약들을 계산하는 단계
    를 추가로 포함하는 ATP 데이터를 관리하기 위한 로컬 이행 관리자 동작 방법.
  71. ATP 데이터를 자동으로 관리하기 위한 방법에 있어서,
    원하는 제품에 각각 대응하는 복수의 요청 품목을 포함하는 제1 ATP 요청을 수신하는 단계;
    상기 요청 품목에 기초하여 하나 이상의 부품 ATP 요청을 생성하는 단계;
    복수의 상기 로컬 이행 관리자(LFM)들 중 적어도 하나로 부품 ATP 요청을 전송하는 단계;
    각각 부품 ATP 요청에 대응하고, 하나 이상의 원하는 대응 제품에 대한 제품 가용성 정보를 포함하는 복수의 부품 견적을 LFM으로부터 수신하는 단계;
    상기 부품 견적에 의해 제공된 제품 가용성 정보에 따라 견적을 생성하는 단계;
    상기 견적을 전송하는 단계
    를 포함하는 ATP 데이터 자동 관리 방법.
  72. 제71항에 있어서,
    개개의 품목에 대한 상기 부품 ATP 요청을 계산하는 단계;
    정보와 규칙에 따라서 상기 부품 견적을 변화시켜 상기 부품 견적이 하나 이상의 거래 제약조건을 동시에(together) 만족시킬 수 있도록 하는 단계
    를 포함하고
    상기 LFM로부터 수신한 부품 견적은 어떻게 상기 부품 견적을 변화시킬 수 있는지에 관한 상기 정보와 규칙을 포함하는
    ATP 데이터 자동 관리 방법.
  73. 제71항에 있어서,
    개개의 품목(item)에 대한 상기 부품 ATP 요청을 계산하는 단계;
    정보와 규칙에 따라서 상기 부품 계약을 변화시켜 상기 부품 계약이 하나 이상의 거래 제약조건을 동시에 만족시킬 수 있도록 하는 단계; 및
    상기 LFM으로 다시 변화된 부품 계약을 전송하여 상기 LFM이 공급 예약(supply reservation)을 조정하는 단계
    를 포함하고
    상기 LFM로부터 수신한 부품 계약은 어떻게 상기 부품 계약을 변화시키는지에 관한 상기 정보와 규칙을 포함하는
    ATP 데이터 자동 관리 방법.
  74. 제71항에 있어서,
    연관된 LFM을 통해 지원된 모든 품목을 포함하는 부품 ATP 요청 및 상기 부품 ATP 요청의 품목으로 신청하는(apply) 상기 ATP 요청에 따라서 모든 거래 제약조건을 계산하는 단계;
    상기 거래 제약조건을 이행하는 부품 견적을 각 LFM으로부터 수신하는 단계;
    상기 ATP 요청에 대응하는 상기 견적을 생성하도록 최종 다수의 품목(multi-item) 부품 견적을 결합시키는 단계
    를 추가로 포함하는 ATP 데이터 자동 관리 방법.
  75. 제71항에 있어서,
    연관된 LFM을 통해 지원된 모든 품목을 포함하는 부품 ATP 요청 및 상기 부품 ATP 요청의 품목으로 신청하는 상기 ATP 요청에 따라서 모든 거래 제약조건을 계산하는 단계;
    상기 거래 제약조건을 이행하는 부품 계약을 각 LFM으로부터 수신하는 단계;
    상기 ATP 요청에 대응하는 단일 계약을 생성하도록 최종 다수의 품목 부품 계약을 결합시키는 단계
    를 추가로 포함하는 ATP 데이터 자동 관리 방법.
  76. 제71항에 있어서,
    상기 LFM들 중 적어도 몇몇은 동일한 제품에 대한 개별적인 할당량을 유지하고,
    상기 제품에 대한 부품 견적을 획득하기 위하여 복수의 LFM을 거쳐 견적 동작을 분산하는 단계를
    를 추가로 포함하는 ATP 데이터 자동 관리 방법.
KR1020017003529A 1998-09-18 1999-09-17 분산된 공급망 설계 환경에서 ａｔｐ 데이터를 관리하기위한 시스템 및 방법 KR20010085823A (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US10096498P 1998-09-18 1998-09-18
US60/100,964 1998-09-18
PCT/US1999/021532 WO2000017795A1 (en) 1998-09-18 1999-09-17 System and method for managing atp data in a distributed supply chain planning environment

Publications (1)

Publication Number Publication Date
KR20010085823A true KR20010085823A (ko) 2001-09-07

Family

ID=22282438

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020017003529A KR20010085823A (ko) 1998-09-18 1999-09-17 분산된 공급망 설계 환경에서 ａｔｐ 데이터를 관리하기위한 시스템 및 방법

Country Status (7)

Country Link
EP (1) EP1114383A1 (ko)
JP (1) JP2002525758A (ko)
KR (1) KR20010085823A (ko)
AU (1) AU5927399A (ko)
CA (1) CA2339805A1 (ko)
TW (1) TW464815B (ko)
WO (1) WO2000017795A1 (ko)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6188989B1 (en) 1995-06-16 2001-02-13 I2 Technologies, Inc. System and method for managing available to promised product (ATP)
US7085729B1 (en) 1995-06-16 2006-08-01 I2 Technologies Us, Inc. System and method for allocating manufactured products to sellers
US7188075B1 (en) * 2000-06-29 2007-03-06 Oracle International Corporation Extended product configuration techniques
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
US7065499B1 (en) 2001-03-19 2006-06-20 I2 Technologies Us, Inc. Intelligent order promising
US7024371B2 (en) 2001-04-13 2006-04-04 I2 Technologies Us, Inc. High availability planning and scheduling architecture
US7043444B2 (en) 2001-04-13 2006-05-09 I2 Technologies Us, Inc. Synchronization of planning information in a high availability planning and scheduling architecture
WO2003003260A1 (en) * 2001-06-28 2003-01-09 Andrew Craig Edlin Quote and supply management system
US7290708B2 (en) 2002-07-31 2007-11-06 Sap Aktiengesellschaft Integration framework
US7209887B2 (en) * 2002-12-13 2007-04-24 Taiwan Semiconductor Manufacturing Company, Ltd. Auto allocation swap system
WO2010106554A2 (en) * 2009-03-20 2010-09-23 Krishna Kumar Mehra A mobile phone based mobile customer relationship loyalty methodology and servicing system with instant analytics features thereof
US9805407B2 (en) 2013-01-25 2017-10-31 Illumina, Inc. Methods and systems for using a cloud computing environment to configure and sell a biological sample preparation cartridge and share related data

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0425405A3 (en) * 1989-10-23 1992-01-22 International Business Machines Corporation An automated customer order promising and confirming method
JPH0457158A (ja) * 1990-06-27 1992-02-24 Fujitsu Ltd 進度照会回答処理装置
TW283220B (ko) * 1994-09-28 1996-08-11 I2 Technologies Inc
US6188989B1 (en) * 1995-06-16 2001-02-13 I2 Technologies, Inc. System and method for managing available to promised product (ATP)

Also Published As

Publication number Publication date
TW464815B (en) 2001-11-21
AU5927399A (en) 2000-04-10
JP2002525758A (ja) 2002-08-13
EP1114383A1 (en) 2001-07-11
WO2000017795A1 (en) 2000-03-30
CA2339805A1 (en) 2000-03-30

Similar Documents

Publication Publication Date Title
US6963847B1 (en) System and method for managing ATP data in a distributed supply chain planning environment
US7249044B2 (en) Fulfillment management system for managing ATP data in a distributed supply chain environment
US20020042755A1 (en) Collaborative fulfillment in a distributed supply chain environment
US7881985B2 (en) Electronic marketplace providing service parts inventory planning and management
US8135630B2 (en) Intelligent fulfillment agents
US8190465B2 (en) Make-to-specification process and data model
US6889197B2 (en) Supply chain architecture
US9767495B2 (en) Different sales and planning product options
US6188989B1 (en) System and method for managing available to promised product (ATP)
US7747481B2 (en) Extreme capacity management in an electronic marketplace environment
US8046276B2 (en) System and method for managing product reserve
US20100161366A1 (en) Product requirement specification in production model
US20020138290A1 (en) System and method for enabling collaborative procurement of products in a supply chain
US20070129984A1 (en) Systems and methods for consolidating order processing items
JPH1097574A (ja) サプライチェーンを横断する拡張企業体プランニングシステム及び方法
US20230004929A1 (en) Load tracking computing platform and user interface
KR20010085823A (ko) 분산된 공급망 설계 환경에서 ａｔｐ 데이터를 관리하기위한 시스템 및 방법
WO2001052158A2 (en) Tupply chain architecture
US11488100B2 (en) Load tracking computing platform and user interface
US20080114634A1 (en) Method, system, and computer program product for determining availability and order scheduling of diverse products and services
WO2002029687A1 (en) Fulfillment management system for managing atp data
MXPA01002867A (en) System and method for managing atp data in a distributed supply chain planning environment
US7664772B2 (en) Method and system for record association management
Campelo A matheuristic for the consistent vehicle routing problem with service level agreements: a case study in the pharmaceutical distribution sector
DE10196726T5 (de) Gemeinsame Ausführung in einer verteilten Lieferkettenumgebung

Legal Events

Date Code Title Description
WITN Application deemed withdrawn, e.g. because no request for examination was filed or no examination fee was paid