Skip to content

fix: Pr fix request for update and create order - #77

Open
Olatomiw wants to merge 1 commit into
ibrahimqarayev:mainfrom
Olatomiw:fix/order_fix
Open

fix: Pr fix request for update and create order#77
Olatomiw wants to merge 1 commit into
ibrahimqarayev:mainfrom
Olatomiw:fix/order_fix

Conversation

@Olatomiw

@Olatomiw Olatomiw commented Feb 3, 2026

Copy link
Copy Markdown
Contributor

Description

This PR addresses critical issues in the order management service identified in #69, improving validation, stock management, and financial accuracy in order creation and update operations.

What I Did

Order Creation (createOrder)

  • ✅ Added validation for null/empty order items with meaningful error messages
  • ✅ Implemented specific InsufficientStockException for better error handling in controller layer
  • ✅ Added stock reduction when orders are placed to maintain inventory accuracy
  • ✅ Implemented proper BigDecimal scale and rounding (setScale(2, RoundingMode.HALF_UP)) for financial calculations
  • ✅ Separated unitPrice and totalPrice for historical price tracking
  • ✅ Added batch product save for efficiency

Order Update (update)

  • ✅ Added validation for null/empty order items
  • ✅ Implemented duplicate product ID detection in update requests
  • ✅ Added comprehensive stock quantity validation considering:
    • Stock returned from removed items
    • Stock needed for new items
    • Stock adjustments for quantity changes on existing items
  • ✅ Implemented price preservation logic:
    • New items capture current product price as unitPrice
    • Existing items preserve their original unitPrice (no price updates)
  • ✅ Added order status validation (only PENDING orders can be updated)
  • ✅ Proper stock adjustments for all scenarios (add/update/remove items)
  • ✅ Added BigDecimal scale and rounding for financial accuracy

Exception Handling

  • ✅ Created InsufficientStockException with detailed stock availability information
  • ✅ Created InvalidOrderRequestException for validation errors
  • ✅ Created OrderNotEditableException for status-based restrictions

Why I Did It

1. Input Validation

Without null/empty checks, the service would throw generic NullPointerException errors that are difficult to debug and provide poor user experience. Explicit validation provides clear, actionable error messages.

2. Specific Exceptions

Generic RuntimeException makes it difficult for the controller layer to differentiate between error types and return appropriate HTTP status codes. Specific exceptions enable:

  • InsufficientProductStockException → HTTP 409 CONFLICT
  • InvalidRequestException → HTTP 400 BAD REQUEST
  • ProductNotFoundException → HTTP 404 NOT FOUND

3. Stock Management

The original implementation validated stock but never reduced it, leading to overselling scenarios. The new implementation:

  • Reduces stock when orders are created
  • Returns stock when items are removed from orders
  • Adjusts stock when quantities change
  • Validates availability considering current allocations

4. Financial Accuracy

Using BigDecimal without scale/rounding can lead to precision issues in financial calculations. Setting scale to 2 decimal places with HALF_UP rounding ensures:

  • Consistent monetary representation
  • Prevents floating-point arithmetic errors
  • Matches standard financial practices

5. Price Preservation

In e-commerce systems, historical price integrity is critical for:

  • Legal/audit requirements
  • Customer trust (prices shouldn't change after ordering)
  • Accurate financial reporting
  • Refund/return calculations

The new implementation stores the price at the time of order creation and preserves it during updates, preventing discrepancies.

6. Duplicate Prevention

Without duplicate detection, submitting the same product multiple times in an update request could create multiple order items for the same product, leading to data inconsistency and incorrect total calculations.

7. Order Status Protection

Allowing updates to shipped or completed orders would create serious business logic violations. Restricting updates to PENDING status ensures data integrity and matches real-world e-commerce workflows.

Testing Recommendations

  • Test order creation with null/empty items list
  • Test order creation with insufficient stock
  • Test stock is properly reduced after order creation
  • Test order update with duplicate product IDs
  • Test order update with insufficient stock
  • Test stock is properly adjusted when updating quantities
  • Test stock is returned when items are removed
  • Test price preservation on existing items during update
  • Test updating non-PENDING orders is rejected
  • Verify BigDecimal calculations are accurate to 2 decimal places

Related Issues

Fixes #69

Breaking Changes

None. This is a backward-compatible bug fix and enhancement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Feature: Implement OrderService and OrderController CRUD endpoints

1 participant