NetSuite Item Pricing Report: Find Margin Leaks in 2026.2

Executive Summary

This report explains how a controller, pricing owner or NetSuite administrator can use the Item Pricing Performance workbook and its new historical dataset to run a repeatable monthly review of configured rates versus realized rates. Oracle's September 2026 monthly release for NetSuite 2026.2 states that the workbook now includes historical pricing data ^[1], and that it reports average sales price, revenue, units sold, cost, margin and sell-through for each price level. The historical dataset is documented as a comparison of configured price-level pricing with realized transaction pricing by item, exact monthly period, currency, subsidiary context and price level ^[2].

Three documented behaviors shape the method. First, realized metrics are calculated only from transactions that use the represented price level ^[2], so a row never blends sales made at a different level. Second, revenue is stated in the base currency of the selected parent company or subsidiary ^[2], so the subsidiary context chosen for the review decides what the numbers mean. Third, the Item Pricing Performance Workbook Details page flags that the view is not in real time ^[3], while totals match the sales pricing reports ^[3]. Applying these two notes to the historical dataset is an inference, because they appear on the workbook details page rather than the historical dataset page. The retrieved Oracle pages do not state an exact refresh delay, so the review should be run after period close and reconciled before any price change is approved.

The report offers a seven-step monthly review, a decision tree that separates four causes of a margin gap (discounting, cost movement, reporting context, and legitimate variance), and a worked example with clearly illustrative numbers. In that hypothetical example, a level configured at $100.00 realizes $94.50, a rate variance of -5.50% and a margin of 28.04% against a 32.00% target. Another row shows a 4.80 point margin gap where only 0.76 points come from price and 4.04 points from an assumed cost increase, so the correct action is a cost review and not a price-level edit.

Context from independent sources keeps expectations realistic. McKinsey's 2003 analysis of an average S&P 1500 income statement found that a 1 percent price rise at stable volume would generate an 8 percent operating profit increase ^[4], but that is an arithmetic illustration, not a forecast for any account. Benchmark margins and discount statistics appear in the Data Analysis section. Nothing in the Oracle documentation quantifies margin improvement; any such figure in this report is a hypothesis to test, not an observed result.

Introduction and Background

The phrase "NetSuite pricing" is ambiguous: it can refer to subscription and licensing prices, which are not the subject here. This report addresses a narrower and more operational question: once a NetSuite account holds price levels, quantity pricing schedules, customer pricing groups and Advanced Pricing rules, how does a finance team learn whether the prices it configured are the prices it actually realizes, and what should it change?

The configuration side is well documented in Oracle's Help Center. NetSuite lets an account define up to 1,000 price levels, apply quantity pricing schedules that create prices for all price levels automatically when applied to an item, and use pricing groups to set customer-specific price levels for groups of items. With Advanced Pricing, price rules automatically apply price levels based on criteria such as customer, item or date range. The realized side is where gaps appear: manual overrides, header-level discounts, contract exceptions and cost movements all separate the configured rate from the rate that lands on an invoice.

Oracle's Sales Pricing Overview dataset already covers transaction lines from invoice, cash sale, cash refund and credit memo records, with fields such as expected amount and variance amount. The new historical Item Pricing Performance dataset adds a period, price-level and subsidiary view that also carries cost and margin. This report treats the two as complementary, separates documented features from inference, and flags every place the documentation is silent.

The intended readers are controllers, revenue-operations managers, pricing owners and administrators in multi-subsidiary distribution and manufacturing. All figures marked illustrative are invented for demonstration, and none of the report asserts that using the workbook raises revenue. As of November 2026, the evidence base is Oracle's own documentation plus independent accounting, statistical and pricing sources; no independent benchmark of the workbook's results exists in the material reviewed.

Key Changes in NetSuite 2026.2

Historical pricing data arrives in the September monthly release

Oracle's version page explains that NetSuite ships two scheduled version upgrades each year, and that enhancements may also arrive in monthly releases between them. The Item Pricing Performance change is listed in the September monthly release for 2026.2. Oracle's release notes are subject to change, so the wording quoted here should be rechecked against the Help Center before it is used in a control document.

An account must be upgraded before it can use the feature, so first confirm the account version and whether the monthly enhancement has arrived. The retrieved pages do not publish a licensing matrix or a dedicated permission list for the workbook. Oracle describes opening it from the Analytics Home page by selecting the Item Pricing Performance card. Related permissions are documented elsewhere in the Help Center: viewing the items, customers and price rules lists on a price level page requires specific permissions, and a role lacking them may see lists that fail to load. Oracle's workbook documentation adds that exporting a table view to a file needs the Export Lists permission. Test access with a real reviewer role during the first cycle.

A configured-versus-realized dataset by item, period, currency, subsidiary and price level

The historical dataset analyzes configured price-level pricing alongside realized transaction pricing by item, exact monthly period, currency and subsidiary context, and price level. The release note adds that configured prices remain visible when related transaction activity is limited or unavailable. A dormant price level therefore still appears, but a row with a configured rate and no realized rate must not be read as a zero-price sale.

The older item-level dataset documents that its prices include line-level and header-level discounts ^[5]. The retrieved page for the historical dataset does not repeat that sentence, so whether the historical realized rate nets header discounts the same way is a point to confirm on a sample transaction during the first review, using the checklist later in this report.

Realized metrics are tied to the price level actually used

Oracle states that realized transaction metrics remain linked to the price level used on each transaction, and that the dataset calculates realized metrics only from transactions that use the represented price level. For a reviewer, this is the feature that makes the comparison fair: the "Distributor 15 percent off" row is judged against sales made at that level, not against a pool of all sales of the item.

The corollary is a limit: a customer sold at a manually typed rate is recorded against whichever level the transaction carries, and the documentation does not say how overrides are classified. The review therefore needs a drill-down to the transaction lines. Oracle's neighboring pivot documentation shows a transaction reference "used for drill-down to the source record", which supports that workflow in the Sales Pricing Overview workbook.

Currency and subsidiary context decide what a number means

Oracle states that revenue in the dataset is based on the base currency of the selected parent company or subsidiary. In a OneWorld account, Oracle's currency documentation explains, each subsidiary can have a separate base currency, and that base currency cannot be changed after the subsidiary record is saved. A report's currency follows the subsidiary selected: Oracle documents that the currency is the base currency of the subsidiary you select, and that consolidated views convert from child to parent base currency using consolidated rates ^[6].

Two sibling pivots in the Sales Pricing Overview workbook reinforce the point. Oracle's sales by price level pivot page lists subsidiary as a row and notes that it impacts permissions and currency context. For a multi-subsidiary distributor, the same item and price level can therefore return different numbers in a subsidiary context and a parent context, so the method below fixes the context first.

Adjacent 2026.2 release pricing changes that affect the review

Several other 2026.2 pricing changes touch the same workflow, though they are not part of the Item Pricing Performance dataset. A NetSuite partner's release summary (Meridian Business) describes expanded pricing transparency on sales order lines, showing whether pricing originates from base pricing, rule-based pricing or customer-specific agreements ^[7], and bulk management of pricing records through the CSV Import Assistant ^[7]. The same partner describes the new datasets as an Item Pricing Performance Metrics dataset providing detailed pricing performance information for active products, and a ready-made workbook built on it ^[7]. That summary is a secondary source; it describes the tools but offers no reconciliation method, and it should be verified against Oracle's pages.

A third change, reported by a changelog site that states its articles are generated from Oracle documentation, is a Sales by Price Rule pivot table in the Sales Pricing Overview workbook ^[8]. Oracle's own pivot page states that transactions with no price rule applied are included in that view ^[9]. These facts bear on whether Advanced Pricing rules can be identified from workbook rows. In the field lists Oracle publishes, a Price Rule field appears in the Sales Pricing Overview pivot but not in the Item Pricing Performance dataset, so rule attribution comes from the Sales Pricing Overview workbook or from the transaction line, not from the Item Pricing Performance row itself.

Data dictionary: what each field means and what it does not tell you

Table 1 below consolidates the fields Oracle lists for the historical and metrics datasets with the definition the review should use. Where Oracle's retrieved pages give no formula, the table says so instead of guessing.

Every row of the table carries an open question, and each has a cheap test: pick one row, open the underlying transactions, and recompute by hand. Realized rate against configured rate answers "are we discounting?", margin against target answers "is the result acceptable?", and sell-through plus units answer "is the sample large enough to act on?" Reviewing the three together prevents cutting or raising a price level on one noisy row.

Implementation Considerations and Process Changes

Prerequisites before the first review

The first cycle works best if four conditions are met. The account must be on a release that includes the September enhancement, which Oracle lists among the 2026.2 monthly enhancements. The reviewer's role must be able to open the workbook and, if evidence is exported, hold the export permission. Price level hygiene must be tolerable, since retired levels create rows nobody owns. And cost data must be credible, since the dataset's cost is labeled an estimate.

Cost deserves attention because gross profit in NetSuite is built on estimates. Oracle notes that the cost of an item on a transaction is often not known until an order is fulfilled ^[10], that gross profit calculations exclude shipping and handling charges, and that average costing is the default inventory costing method. Per the same documentation set, the costing method cannot be changed after it is saved on the item record, and in OneWorld accounts the item-defined cost estimate converts to the transaction currency using the transaction subsidiary's exchange rate. A reviewer should therefore know, per item family, which method is in force, and should expect estimated margin to differ from the margin that reaches the general ledger.

A seven-step monthly variance review

The method below is the report's own recommendation, not an Oracle procedure.

• Step 1, close the window. Run the review after the period closes for the subsidiaries in scope, because Oracle states the view is not in real time. The retrieved pages publish no refresh delay, so record each run's timestamp against the last known posting.
• Step 2, fix the context. Choose one period, one subsidiary or parent context, and one currency basis, and keep them identical across cycles. Revenue follows the selected context, and a subsidiary's functional currency is the currency of its primary economic environment ^[11].
• Step 3, screen for materiality. Sort rows by revenue and units. Discard rows below a threshold set in advance (for example, fewer than 20 transactions or revenue under a floor the controller approves), and list them as "insufficient evidence". NIST notes that no correct sample size exists without additional assumptions ^[12].
• Step 4, compute the variances. For each remaining row calculate rate variance % as (realized rate - configured rate) / configured rate, and margin gap in points as realized margin minus target margin; this mirrors the price-realization logic BCG describes, comparing actual prices or discounts with their target levels ^[13]. Weight any roll-up by units, never by a simple average of row percentages.
• Step 5, decompose the margin gap. Separate the price effect (realized price against configured price at the baseline cost) from the cost effect (change in estimated cost at the realized price). The worked example below shows the arithmetic.
• Step 6, drill to transactions. Open the underlying lines for rows that pass the screen. Check the price level on the line, the rate typed, any header discount, and the applied rule where available through the Sales Pricing Overview workbook.
• Step 7, decide and record. Apply the decision tree, record the rationale, and route any level or rule change through the approval step in the controls section.

Reviewers who start with the biggest percentage gap tend to find the thinnest rows; an outlier is, in NIST's wording, an observation that appears to deviate markedly from other observations in the sample ^[14]. NIST also notes that an outlier may indicate bad data ^[14], so a large gap is not automatically a pricing fault, which is why the transaction drill-down comes before the decision.

The decision tree

The tree has four branches, summarized in Table 2 later and described here.

• Branch A, price gap with stable cost. Realized rate is materially below the configured rate and estimated cost is flat. Examine discounts, manual rates and rule outcomes at transaction level. If the lower rate is an unapproved pattern, amend the rule or tighten approvals; if it is a documented contract, retain the price and re-label the row.
• Branch B, margin gap with stable price. Realized rate is close to configured but margin is below target. Examine cost: receipts, costing method, landed cost settings, and return costs. Oracle notes a calculated return cost might not be the same each time. Revise the price level only after the cost movement is confirmed as durable.
• Branch C, positive variance or thin volume. Realized rate exceeds configured rate on few units. Hold; log the row; revisit next cycle.
• Branch D, context difference. The gap appears only in one subsidiary or only in a parent view. Re-run in the subsidiary's own base currency before drawing any conclusion.

Each branch ends in one of three outputs: amend a price level or rule, change a cost or process input, or retain and document. A review that can only recommend price changes drifts toward unnecessary ones.

Table 2 below turns the branches into a diagnostic matrix that can be pasted into the review template.

Only the first two rows are likely to end in a pricing or cost action, and even they require transaction evidence. The fifth row is deliberately passive: Oracle documents sell-through as a metric but its retrieved pages give no formula, so a low value is a prompt for questions, not a trigger for a price cut.

Worked example (Hypothetical Example)

The following numbers are invented for demonstration and do not describe any real company, item or account. Consider one item, SKU-100, sold by a US subsidiary with a USD base currency in one month. The formulas are:

• Rate variance % = (realized rate - configured rate) / configured rate.
• Realized margin = (realized rate - estimated cost) / realized rate.
• Margin gap = realized margin - target margin, in percentage points.

Gross margin is measured on the selling price, which differs from markup on cost; an extension-service example shows that a $0.25 markup on a $1.00 cost gives a $1.25 price and a 20% gross margin on the selling price ^[15]. Mixing the two conventions creates apparent leakage, so state which one the target field uses.

Table 3 below shows three price-level rows for the month. Row A is a discount pattern, Row B is a cost movement, and Row C is a thin positive row.

Row A: (94.50 - 100.00) / 100.00 = -5.50%. Revenue is 1,200 x $94.50 = $113,400, and the price shortfall against configured is 1,200 x $5.50 = $6,600. Margin is (94.50 - 68.00) / 94.50 = 28.04%, 3.96 points under target. Because estimated cost equals the baseline cost of $68.00 that supports the 32% target at the configured rate, the entire gap is price.

Row B: (79.20 - 80.00) / 80.00 = -1.00%. If baseline cost was $60.00 (a 25% margin at $80.00) and estimated cost is now $63.20, realized margin is (79.20 - 63.20) / 79.20 = 20.20%, a gap of 4.80 points. The price effect is (79.20 - 60.00) / 79.20 = 24.24% against 25.00%, or -0.76 points; the cost effect is 20.20% minus 24.24%, or -4.04 points. The two sum to -4.80. Seen alone, the margin gap might prompt a price edit; the decomposition points to the cost input, so Branch B applies.

Row C: realized rate is +9.17% above configured on only 12 units, so the Step 3 screen holds it.

Across rows A and B, realized revenue is $137,160 against $144,000 at configured rates, a shortfall of $6,840 or 4.75%. Of that, $6,600 sits in Row A. This is a hypothesis, not proof of leakage; Row A may be a legitimate contract.

A currency illustration shows why context matters. Suppose a Canadian subsidiary with a CAD base currency has a configured level rate of CAD 135.00 and realizes CAD 128.00, a variance of -5.19%. If an analyst translates the realized rate at an assumed 0.7400 USD per CAD to USD 94.72 and divides it by the untranslated CAD 135.00, the apparent variance is -29.84%. Oracle documents that revenue follows the selected base currency; whether the configured level rate is displayed in the same currency is exactly the kind of open question Table 1 lists, so confirm both sides share one currency before computing a ratio.

The example supports three practical notes: compute variances in one currency, show cost and price effects separately, and keep the screen and decomposition in the evidence pack.

When the workbook can mislead

• Not real time. Oracle states the view is not in real time. Oracle's accounting period documentation states that transactions post in real time, so a row can lag a transaction that a saved search already shows.
• Posting period versus transaction date. When accounting periods are used, Oracle's documentation requires a posting period on the transaction, and a credit memo also carries a posting period.
• Returns and credits. Oracle's returns documentation states that returns always generate a credit memo, and that by default refunds and exchanges can only occur if the accounting period is open. The retrieved Oracle pages do not state how the Item Pricing Performance dataset nets returns, so reconcile a month with known credits before trusting margin.
• Sparse transactions. A row built from a handful of invoices can swing on one deal; NIST points out that sample-size questions have no correct answer without assumptions ^[12].
• Estimated cost. Gross profit uses estimates and not always the cost eventually posted.
• Exchange rate regimes. Oracle documents that consolidated reports use a separate consolidated exchange rates table, recommends auto-calculating consolidated rates before closing the period, and a report can show values calculated with only the current exchange rate. Different rate regimes can give different totals for the same sales.
• Multi-currency price lists. Oracle's pricing documentation states that with Multiple Currencies, item prices are set separately for each currency, with a price entered per level in the selected currency; if none is set, NetSuite converts the base currency price. A configured rate for a foreign-currency customer may therefore be a converted value.

Review and approval controls

Controls should separate the person who finds a gap from the person who changes a price, and should list volume discounts and rebates that sit outside invoice lines ^[16]. A workable pattern: the analyst prepares the worksheet, the pricing owner proposes a change, the controller approves, and an administrator executes. Oracle documents a Mass Update function for item prices, and the partner summary notes bulk import of pricing records ^[7]; both are powerful, so export the old values before each batch and rerun the review the following month.

Keep an evidence pack: the variance worksheet, the exported table view, the transaction samples, the cost checks, and the decision memo. Export has limits worth testing: Oracle documents that a table view can be saved to a CSV file, but pivot exports omit percentages, currency symbols and totals ^[17], so recompute totals in the spreadsheet and label currency in a header.

Source-to-GL validation checklist

Run these checks once per cycle before relying on the numbers.

• Totals tie to sales pricing reports. Oracle states workbook totals match the sales pricing reports; compare the workbook total for the chosen context to the report.
• Totals tie to a transaction search. A standard transaction saved search on the same lines and period should agree. Oracle's Sales Pricing Overview template is not based on a saved search, so a saved search is an independent check, and gross profit fields can be added to advanced and saved searches of transactions.
• Revenue ties to the general ledger. Compare posting-period revenue by subsidiary to the ledger, with credit memos included.
• Currency basis is identical. Confirm base currency, rate table and period for every subsidiary.
• Cost reconciles to cost of goods sold. Compare estimated cost times units to posted cost of goods sold for a sample of items.
• Discount treatment is understood. Check one invoice with a header discount to see whether the realized rate nets it. The Net Amount definition in the Sales Pricing Overview is amount minus posting discount.
• Rules are traceable. For rows flagged as rule-driven, confirm the rule from the Sales Pricing Overview pivot or the line.

If any check fails, document the difference and hold price changes until it is explained.

Data Analysis and Evidence

The Oracle documentation is silent on how much margin a review can recover, and no independent benchmark of this workbook exists in the sources reviewed. The evidence below is therefore indirect: it shows why price realization is a legitimate review target and how widely target margins vary.

Price realization in the research literature

McKinsey's 2003 analysis, published in The McKinsey Quarterly ^[4], states that for the average S&P 1500 income statement a 1 percent price rise at stable volume would generate an 8 percent increase in operating profit ^[4]. The same article describes the pocket price waterfall as a tool that still helps identify transaction-pricing opportunities ^[4]. Both statements describe a company-level arithmetic illustration from a specific year and sample. They are not forecasts and not evidence that any workbook produces a gain.

Bain reports, from its own client experience, that almost one-third of discounts and other forms of investment in customers are wasted ^[18]. The retrieved page publishes no sample, so it is a reason to examine discount patterns, not a rate to expect. BCG, writing about sales incentives, notes that price-realization metrics compare actual prices or discounts with their target levels ^[13], which is the same logic as the realized-versus-configured comparison here, and reports that fewer than 10% of incentive plans it reviewed include any price-based metrics ^[13]. BCG also reports that variable pay averages around 40% of total sales compensation in its experience ^[13]. The implication for NetSuite teams is organizational: a price-variance report has limited effect if nobody is rewarded or measured on it.

Target margins vary by business model

The figures below, all taken from the companies' own annual reports, show the spread a controller should expect when setting target margins.

• W.W. Grainger, fiscal 2025: consolidated gross profit margin of 39.1%, down 30 basis points ^[19]; the High-Touch Solutions North America segment reported 41.7% ^[19] and the Endless Assortment segment 29.9% ^[19].
• Fastenal, 2025: gross profit of 45.0% of net sales against 45.1% a year earlier ^[20].
• Applied Industrial Technologies, fiscal 2026: gross profit margin of 30.3% in both 2026 and 2025 ^[21], with higher LIFO expense offset by price contribution and channel execution ^[21].

The range from roughly 30% to 45% across these three filers shows that a single company-wide target margin is a blunt instrument. The figures are not benchmarks for a specific account and should not be loaded into the Target Profit Margin field.

Census Bureau data provide the market backdrop: the Annual Wholesale Trade Survey is described as the only source of current purchases and gross margin data for merchant wholesalers ^[22].

Accounting rules that shape what counts as price

Volume discounts and rebates are not always visible on the invoice line. A Big Four technical guide lists price concessions, volume discounts and rebates among forms of variable consideration under ASC 606 ^[16], and notes that arrangements with retroactive volume discounts include variable consideration because the transaction price is not known until the threshold is resolved ^[16]. The IFRS 15 standard page states that where contract consideration includes a variable amount, an entity must estimate it ^[23]; the same page defines the transaction price as the amount of consideration to which an entity expects to be entitled ^[23]. For a pricing review the consequence is that a realized invoice rate may overstate the final net price when rebates are accrued separately, so rebate accruals should be listed beside the worksheet. The same guide states that rebate amounts enter the transaction price only if it is probable that a significant reversal of cumulative revenue will not occur ^[16].

Currency translation has its own rules. IAS 21 defines functional currency as the currency of the primary economic environment in which the entity operates ^[11] and covers translating a foreign operation's statements into the entity's functional currency ^[11], and into a presentation currency where that differs ^[11]. The older FASB Statement No. 52 states that translation adjustments are kept out of net income ^[24]. These definitions explain why a subsidiary's base-currency margin and a parent-currency margin may differ without any change in price.

Implications and Future Directions

For finance teams, the main implication is a change of unit of work: instead of auditing prices when a customer complains, the team reviews a fixed table each month and acts on exceptions. That pays off only if the data are trustworthy, so treat the first three cycles as calibration: reconcile totals, test one row by hand, and record which open questions in Table 1 have been answered.

For administrators, price rule governance becomes the larger task. Advanced Pricing evaluates customer-specific rules first, then customer record pricing, then rules for all customers, and finally the item's base price level, with a tie-breaker preference where more than one level is returned. A divergent realized rate may simply reflect the hierarchy working as configured, so record rule order in the review notes.

Oracle's AI-generated pricing summaries on item records are documented as varying each time they are generated, so they should not be pasted into an evidence pack as fixed text. The Help Center itself changes weekly, and the historical dataset may gain fields or refresh documentation, so recheck it each quarter. Organizations that want outside help with price levels, SuiteAnalytics datasets or review controls can engage a NetSuite administration partner and should choose on references and fit.

Uncertainty remains about whether enough users have transaction history and clean cost data to benefit. A business with sparse sales per level, unstable estimated cost, or heavy credit memo activity may find that most rows fail the Step 3 screen; the sensible response is to fix data before debating prices.

Frequently Asked Questions (FAQs)

What is the NetSuite item pricing report in 2026.2?

It is the Item Pricing Performance workbook, which now includes historical pricing data comparing configured item prices with realized transaction performance. It is not a subscription price list.

How to run a NetSuite pricing analysis or margin analysis by item

Use the monthly review above: fix period and subsidiary, screen by volume, compute rate variance and margin gap, split price from cost, drill to transactions, then decide.

Is there a NetSuite price level report?

The Sales Pricing Overview workbook groups sales transactions by price level, subsidiary, amount and date, and shows totals that match the sales pricing reports. The Item Pricing Performance workbook adds realized margin per price level.

Can an item pricing saved search replace the workbook?

Yes, as a control. Gross profit fields can be added to advanced and saved searches of transactions, which gives an independent total to compare with the workbook.

How do quantity pricing schedules and customer pricing groups show up in the review?

They are configured prices. A quantity pricing schedule creates prices for all price levels when applied to an item, and pricing groups set customer-specific levels for groups of items. In the review they appear as the configured rate for whichever level a transaction carries.

Is there a NetSuite gross margin report?

Oracle's gross profit documentation states that no reports were created specifically for gross profit; instead, gross profit fields can be added to most sales reports. Those fields use estimated cost, so reconcile them with the ledger.

How to find margin leaks in NetSuite

Start with rows where realized rate is below the configured rate on material volume, confirm the cause at transaction level, and separate price from cost effects before acting. Treat the result as a leakage hypothesis until transactions confirm it.

Conclusion

The 2026.2 historical Item Pricing Performance dataset gives finance teams a way to compare configured rates with realized rates and margins by item, month, currency, subsidiary and price level, and Oracle documents that realized metrics use only transactions at the represented price level. Its limits are equally documented: the view is not real time, revenue follows the selected base currency, and cost is an estimate.

A disciplined monthly review turns those facts into a method. Fix the context, screen for volume, calculate the variances, split price from cost, drill into transactions, and finish with one of three outcomes: amend, correct an input, or retain and document. The report does not claim that doing so raises margin; it claims that the review makes the reasons for a gap visible and ties pricing changes to evidence. Readers should confirm the open questions in Table 1 on their own data during the first cycle and revisit the method as Oracle's documentation evolves.