RFC: Unifying Direct Orders into CustomerOrder

1. Objective

Consolidate the conceptually fragmented direct_order_i and direct_order_ii DocTypes (traditionally split between AFD-I and AFD-II models) into a single, unified CustomerOrder table. This shift centralizes the business logic, reduces schema duplication, and provides a scalable routing architecture based on distinct category tags rather than isolated database tables.

2. Proposed Architecture

Instead of utilizing hardcoded tables for separate order flows, the CustomerOrder table will utilize two distinct categorical fields to decouple Compliance / Business Logic from Supply Chain Logistics.

2.1 Order Category (order_category)

Dictates what is being ordered. This field handles legal, compliance, and business groupings.

• Standard: Regular consumer items and general orders.
• Dropship: Items shipped directly from vendors.
• Special_Demand: Specially negotiated, bulk, or high-value procurement requests.
• Classified: Sensitive products requiring restricted visibility.
• Restricted: Highly regulated goods requiring explicit clearance and compliance checks (e.g., Weapons).

2.2 Fulfillment Method (fulfillment_method)

Dictates how it gets to the user. This field explicitly targets supply chain flow and operational routing.

• dealer_direct: The dealer directly supplies the item to the customer (Replaces the physical routing of AFD-I / direct_order_i).
• DC_Pickup: The customer picks up the fulfillment from the Distribution Center (Replaces the physical routing of AFD-II / direct_order_ii).
• Store_Pickup: Standard store fulfillment where the customer secures the product from their local Retail Outlet.

3. Scope & Migration Impact

• Schema Construction: Adding CustomerOrder to libs/wms/doctypes. Consolidating all fields previously resident in direct_order_i and direct_order_ii (like customer, business_price, outlet).
• Logic Routing: Transitioning services from checking if isinstance(order, DirectOrderI) to utilizing if order.fulfillment_method == 'dealer_direct'.
• Simplification / Cleanup: Deprecation and explicit removal of the direct_order_i and direct_order_ii sub-modules.
• Upstream Dependencies: The supplier_api and supplier_portal_service will now consume one uniform payload definition for external orders.

4. Implementation Steps

1. Scaffold the Unified DocType

   • Create libs/wms/src/wms/doctypes/customer_order.
   • Define CustomerOrder in doctype.py applying the unified properties and setting table_name = "customer_order".
   • Add order_category and fulfillment_method as enumerations.

2. Merge Controller Logic

   • Combine the validation hooks in DirectOrderIController and DirectOrderIIController into CustomerOrderController.
   • Implement logical branching dependent on order_category (for compliance checks) and fulfillment_method (for status/delivery orchestration).

3. Refactor Integrated Services

   • Update SupplierPortalService and API route aggregators to query and accept the single CustomerOrder interface.
   • Refactor queries that previously performed bulk pulls across both models.

4. Deprecate Legacy Models

   • Delete libs/wms/src/wms/doctypes/direct_order_i (and afd_order_i).
   • Delete libs/wms/src/wms/doctypes/direct_order_ii (and afd_order_ii).

5. Test Assertions

   • Implement unit tests mapping scenarios: e.g., validating that setting fulfillment_method = "dealer_direct" accurately shadows the original AFD-I supply chain rules.