Refactor and Optimize Revenue Calculation Function

Efficient and accurate financial calculations are critical for any business. You've been presented with an existing pseudocode function designed to compute a modified total revenue from transaction data. While it currently works, it suffers from readability issues, potential inefficiencies, and could be structured more robustly. Your task is to improve this function, making it a professional and high-performing piece of code.

Problem Description

You are given an existing pseudocode function, calculate_gross_sales, which aims to compute a modified total revenue from a list of transaction_records. Each transaction object in this list contains a status (e.g., "completed", "pending", "cancelled") and a list of items_purchased. Each item_entry object within items_purchased has price_per_unit, qty, and is_premium attributes.

The intended business logic for the total gross_sales calculation is as follows:

1. Only consider transaction records where status is "completed".
2. For each completed transaction, calculate an initial current_transaction_subtotal by summing price_per_unit * qty for all valid item_entry objects (where price_per_unit > 0 and qty > 0). Invalid items should not contribute to the subtotal.
3. If this current_transaction_subtotal exceeds 500, a 10% volume discount should be applied to it (i.e., multiply by 0.9).
4. Additionally, for each item_entry in the transaction where is_premium is TRUE, a fixed premium_bonus of 10 should be added to that transaction's value.
5. The final total_adjusted_revenue is the sum of these adjusted values from all completed transactions.

Your primary goal is to improve the provided calculate_gross_sales function. The improved function should adhere to the exact same business logic and produce the identical output as the original for all valid inputs, but it must be:

• Correct: No functional changes; the output must match the original.
• Efficient: Reduce redundant computations or unnecessary iterations to improve performance.
• Readable: Employ clear variable names and structure the logic in a way that is easy to understand and maintain.
• Robust: Handle specified edge cases gracefully (e.g., empty input lists, transactions with no valid items).

Original (Flawed) Pseudocode for Reference:

// Original Function (do not modify this directly, use it as a reference for logic)
FUNCTION calculate_gross_sales(transaction_records):
    total_adjusted_revenue = 0

    FOR EACH transaction IN transaction_records:
        IF transaction.status IS "completed":
            current_transaction_subtotal = 0
            // First pass to calculate subtotal
            FOR EACH item_entry IN transaction.items_purchased:
                IF item_entry.price_per_unit > 0 AND item_entry.qty > 0:
                    current_transaction_subtotal = current_transaction_subtotal + (item_entry.price_per_unit * item_entry.qty)
            
            // Apply volume discount
            IF current_transaction_subtotal > 500:
                current_transaction_subtotal = current_transaction_subtotal * 0.9 
            
            // Second pass to calculate premium item bonus (potential inefficiency)
            premium_bonus_for_transaction = 0
            FOR EACH item_entry IN transaction.items_purchased:
                IF item_entry.is_premium IS TRUE:
                    premium_bonus_for_transaction = premium_bonus_for_transaction + 10 
            
            total_adjusted_revenue = total_adjusted_revenue + current_transaction_subtotal + premium_bonus_for_transaction
        END IF
    END FOR
    RETURN total_adjusted_revenue
END FUNCTION

Examples

Example 1:

Input:
transaction_records = [
    {
        status: "completed",
        items_purchased: [
            {price_per_unit: 100, qty: 3, is_premium: FALSE},  // Subtotal part: 300
            {price_per_unit: 50, qty: 1, is_premium: TRUE}    // Subtotal part: 50, Premium bonus: 10
        ]
    },
    {
        status: "pending", // This transaction should be ignored
        items_purchased: [
            {price_per_unit: 200, qty: 1, is_premium: FALSE}
        ]
    },
    {
        status: "completed",
        items_purchased: [
            {price_per_unit: 300, qty: 2, is_premium: TRUE},   // Subtotal part: 600, Premium bonus: 10
            {price_per_unit: 100, qty: 1, is_premium: FALSE} // Subtotal part: 100
        ]
    }
]

Output: 1000

Explanation:

• Transaction 1 (completed):
  • Subtotal calculation: (100 * 3) + (50 * 1) = 300 + 50 = 350.
  • Discount check: 350 is not > 500, so no discount. Subtotal remains 350.
  • Premium bonus: 1 premium item (50x1), so 1 * 10 = 10.
  • Adjusted value for Transaction 1 = 350 + 10 = 360.
• Transaction 2 (pending): Ignored.
• Transaction 3 (completed):
  • Subtotal calculation: (300 * 2) + (100 * 1) = 600 + 100 = 700.
  • Discount check: 700 is > 500, so apply 10% discount. Subtotal becomes 700 * 0.9 = 630.
  • Premium bonus: 1 premium item (300x2), so 1 * 10 = 10.
  • Adjusted value for Transaction 3 = 630 + 10 = 640.
• Total Adjusted Revenue: 360 (from T1) + 640 (from T3) = 1000.

Example 2:

Input:
transaction_records = [
    {
        status: "pending", // Ignored
        items_purchased: [
            {price_per_unit: 10, qty: 1, is_premium: FALSE}
        ]
    },
    {
        status: "completed",
        items_purchased: [] // Empty items list
    },
    {
        status: "completed",
        items_purchased: [
            {price_per_unit: -5, qty: 10, is_premium: TRUE},   // Invalid item (price <= 0)
            {price_per_unit: 20, qty: 0, is_premium: FALSE}    // Invalid item (qty <= 0)
        ]
    }
]

Output: 0

Explanation:

• Transaction 1 (pending): Ignored.
• Transaction 2 (completed): items_purchased is empty. Subtotal = 0. No discount. Premium bonus = 0. Adjusted value = 0.
• Transaction 3 (completed): Both items are invalid according to the business logic (price_per_unit > 0 and qty > 0). Subtotal = 0. No discount. Premium bonus = 0. Adjusted value = 0.
• Total Adjusted Revenue: 0 + 0 + 0 = 0.

Constraints

• transaction_records list length: 0 to 100,000.
• items_purchased list length per transaction: 0 to 1,000.
• price_per_unit: Can range from -100 to 1,000 (integers or floats). Only values > 0 contribute to subtotal.
• qty: Can range from -10 to 100 (integers). Only values > 0 contribute to subtotal.
• status: STRING, one of "completed", "pending", "cancelled".
• is_premium: BOOLEAN (TRUE/FALSE).
• The improved function should aim for a time complexity better than O(N * M * 2), where N is the number of transactions and M is the average number of items per transaction. An ideal solution would approach O(N * M).
• Space complexity for auxiliary data structures should be O(1) beyond input storage.

Notes

• Your primary focus should be on refactoring the existing pseudocode to be more efficient and readable, while strictly maintaining the original business logic.
• Look for opportunities to combine processing steps that iterate over the same data.
• Consider breaking down the logic for a single transaction into smaller, clearly named intermediate variables or helper functions (if applicable in pseudocode).
• Use descriptive variable names that reflect their purpose, improving the function's self-documentation.
• The problem specifically asks for improving the given logic, not changing the business rules. Your improved function must produce identical results to the original for all valid inputs.