Certification Exam Preparation

Overview

• What you’ll learn:
  • How the iDempiere Developer Certification exam is structured, what topics it covers, and how to prepare effectively
  • How to review key concepts from each module — Architecture, Plugin Development, Production, and Financial Management — with targeted practice scenarios
  • How to approach exam questions strategically, manage your time, and connect certification to career development
• Prerequisites: Lessons 1-46 (complete iDempiere learning curriculum across all paths)
• Estimated reading time: 25 minutes

Introduction

You have reached the final lesson of the iDempiere learning curriculum. Over the previous 46 lessons, you have built comprehensive knowledge spanning iDempiere’s architecture, data model, configuration, customization, production, financial management, performance optimization, integration, and implementation methodology. This lesson helps you consolidate that knowledge and prepare for the certification exam that validates your expertise.

Certification serves multiple purposes: it validates your skills to employers and clients, it forces a comprehensive review that deepens your understanding, and it connects you to a community of certified professionals. Whether or not you plan to take the exam immediately, the review process in this lesson will strengthen your command of the material.

Exam Overview and Format

The iDempiere Developer Certification exam tests both theoretical knowledge and practical skills. Understanding the format helps you prepare efficiently.

Exam Structure

• Section 1: Multiple-Choice Questions (60% of the exam). These test conceptual understanding, architectural knowledge, and decision-making ability. Questions range from straightforward factual recall to scenario-based questions that require analysis and judgment.
• Section 2: Hands-On Coding Exercises (40% of the exam). These require you to write actual Java code — implementing model validators, callouts, processes, or plugin configurations. You will work in a provided iDempiere development environment.

Exam Topics Distribution

Passing Criteria

You must achieve a passing score on both sections — the multiple-choice section and the hands-on section — to earn certification. A strong performance in one section cannot compensate for a failing score in the other. This ensures that certified developers have both theoretical knowledge and practical coding ability.

Architecture Module Review

The Architecture module covers the foundational knowledge of how iDempiere is built and operates. This is tested primarily through multiple-choice questions.

Key Concepts to Review

• Three-tier architecture: Be able to describe the database tier (PostgreSQL/Oracle), application tier (Java/OSGi/Equinox), and presentation tier (ZK Framework). Understand the responsibilities of each tier and how they communicate.
• OSGi and Eclipse Equinox: Understand bundles, services, extension points, and the lifecycle of OSGi components. Know how iDempiere uses OSGi for modularity and plugin architecture.
• Application Dictionary: Understand the AD tables (AD_Table, AD_Column, AD_Window, AD_Tab, AD_Field, AD_Process, AD_Reference) and how they define the user interface and behavior. Be able to explain model-driven development — how changes in the AD automatically reflect in the UI without code changes.
• Database design patterns: Understand the standard columns (AD_Client_ID, AD_Org_ID, IsActive, Created/Updated/CreatedBy/UpdatedBy), the multi-tenant data model, soft delete pattern, and the document processing framework (DocAction, DocStatus).
• Caching: Understand how iDempiere caches Application Dictionary metadata and reference data. Know the CCache class and cache invalidation patterns.

Common Exam Questions (Architecture)

Q: What is the primary advantage of iDempiere’s Application Dictionary approach compared to hardcoded UI definitions?

A: The Application Dictionary stores UI definitions (windows, tabs, fields, processes) as data in the database rather than in code. This enables runtime modification of the user interface through configuration changes without recompiling or redeploying the application. It also enables features like role-based field visibility, dynamic validation, and metadata-driven code generation.

Q: Explain the difference between an OSGi extension point and an OSGi service. How does iDempiere use each?

A: An extension point is a declared place where plugins can contribute functionality (e.g., adding a new process factory, model factory, or form factory). Extensions are typically declared in plugin.xml files. An OSGi service is a Java object registered in the OSGi service registry that implements a defined interface, allowing other bundles to discover and use it at runtime. iDempiere uses extension points for UI contributions (forms, processes, infopanels) and services for business logic extensions (model validators, event handlers, callouts).

Q: Why does every iDempiere table include AD_Client_ID and AD_Org_ID columns?

A: These columns implement multi-tenant data isolation. AD_Client_ID separates data between completely independent business entities (tenants). AD_Org_ID further segments data by organizational unit within a client. The security framework uses these columns to enforce data access rules — users can only see and modify records belonging to their authorized clients and organizations. This enables a single database to securely serve multiple tenants.

Plugin Development Module Review

The Plugin Development module is the most heavily weighted section and includes both multiple-choice questions and hands-on coding exercises.

Key Concepts to Review

• Model Validators: Know how to implement IModelValidator and register it as an OSGi component. Understand the timing constants (TIMING_BEFORE_SAVE, TIMING_AFTER_SAVE, TIMING_BEFORE_DELETE, etc.) and document validation timings (TIMING_BEFORE_COMPLETE, TIMING_AFTER_COMPLETE, etc.). Know when to return null (success) vs. a string (error message).
• Callouts: Understand the difference between callouts and model validators. Know how to implement IColumnCallout and register it. Remember that callouts are UI-level events — they fire when a user changes a field, not during programmatic saves.
• Processes: Be able to implement a SvrProcess subclass. Know how to declare process parameters (in the Application Dictionary and retrieved via getParameter()), log progress, and return success or failure.
• Event Handlers: Understand iDempiere’s event system based on OSGi EventAdmin. Know the event topics (e.g., IEventTopics.PO_BEFORE_NEW) and how to register event handlers using Declarative Services.
• Plugin packaging: Understand MANIFEST.MF (bundle name, version, imports, exports), component.xml (OSGi Declarative Services), and 2Pack for deploying Application Dictionary changes.

Practice Scenario: Model Validator

Task: Write a model validator that prevents a sales order from being completed if the total exceeds the customer’s credit limit.

@Component(name = "com.example.CreditLimitValidator",
           immediate = true,
           service = IModelValidator.class)
public class CreditLimitValidator implements IModelValidator {

    private int clientId = -1;

    @Override
    public void initialize(ModelValidationEngine engine, MClient client) {
        if (client != null) clientId = client.getAD_Client_ID();
        engine.addDocValidate(MOrder.Table_Name, this);
    }

    @Override
    public int getAD_Client_ID() {
        return clientId;
    }

    @Override
    public String login(int AD_Org_ID, int AD_Role_ID, int AD_User_ID) {
        return null;
    }

    @Override
    public String modelChange(PO po, int type) throws Exception {
        return null;
    }

    @Override
    public String docValidate(PO po, int timing) {
        if (timing == TIMING_BEFORE_COMPLETE) {
            MOrder order = (MOrder) po;

            // Only check sales orders
            if (!order.isSOTrx()) return null;

            MBPartner bp = new MBPartner(order.getCtx(),
                order.getC_BPartner_ID(), order.get_TrxName());

            BigDecimal creditLimit = bp.getSO_CreditLimit();
            if (creditLimit == null || creditLimit.signum() == 0)
                return null; // No limit set

            BigDecimal creditUsed = bp.getSO_CreditUsed();
            BigDecimal orderTotal = order.getGrandTotal();
            BigDecimal totalExposure = creditUsed.add(orderTotal);

            if (totalExposure.compareTo(creditLimit) > 0) {
                return "Credit limit exceeded. Limit: " +
                    creditLimit + ", Current exposure: " +
                    creditUsed + ", Order total: " + orderTotal;
            }
        }
        return null;
    }
}

This example demonstrates the essential patterns: component annotation for OSGi registration, implementing the interface methods, registering for specific document events, and returning null for success or an error message for failure.

Practice Scenario: Process

Task: Write a process that updates the credit status of all business partners based on their payment history.

public class UpdateCreditStatusProcess extends SvrProcess {

    private int daysOverdue = 30;

    @Override
    protected void prepare() {
        for (ProcessInfoParameter param : getParameter()) {
            if ("DaysOverdue".equals(param.getParameterName())) {
                daysOverdue = param.getParameterAsInt();
            }
        }
    }

    @Override
    protected String doIt() throws Exception {
        int updated = 0;
        int total = 0;

        String sql = "SELECT DISTINCT C_BPartner_ID FROM C_Invoice " +
            "WHERE IsSOTrx='Y' AND IsPaid='N' AND " +
            "PaymentTermDueDate(C_PaymentTerm_ID, DateInvoiced) " +
            "< addDays(getDate(), -?) " +
            "AND AD_Client_ID = ?";

        PreparedStatement pstmt = DB.prepareStatement(sql, get_TrxName());
        pstmt.setInt(1, daysOverdue);
        pstmt.setInt(2, getAD_Client_ID());
        ResultSet rs = pstmt.executeQuery();

        while (rs.next()) {
            total++;
            int bpId = rs.getInt(1);
            MBPartner bp = new MBPartner(getCtx(), bpId, get_TrxName());

            if (!"X".equals(bp.getSOCreditStatus())) {
                bp.setSOCreditStatus("X"); // Credit Hold
                bp.saveEx();
                updated++;
                addLog("Set credit hold: " + bp.getName());
            }
        }
        DB.close(rs, pstmt);

        return "Reviewed " + total + " partners, " +
               updated + " placed on credit hold";
    }
}

Production Module Review

The Production module tests your understanding of production planning, execution, and costing within iDempiere.

Key Concepts to Review

• Bill of Materials (BOM): Understand multi-level BOMs, BOM types (make-to-order, make-to-stock), phantom assemblies, component quantity calculations, and BOM versioning. Know the difference between PP_Product_BOM (header) and PP_Product_BOMLine (components).
• Material Requirements Planning (MRP): Understand the MRP calculation logic — gross requirements, scheduled receipts, projected on-hand, net requirements, planned orders. Know MRP parameters (lead time, safety stock, order quantity policies) and how MRP handles multi-level BOMs (explosion).
• Production Orders: Understand the production order lifecycle (drafted, in progress, completed, closed). Know how material issues (component consumption) and receipts (finished goods output) are recorded. Understand cost collection on production orders.
• Costing methods: Understand standard cost (predefined cost used for variance analysis), average cost (weighted moving average), and actual cost (specific job costing). Know how each method values inventory and recognizes production variances.

Common Exam Questions (Production)

Q: Explain the difference between a phantom BOM and a regular BOM. When would you use a phantom BOM?

A: A phantom BOM (also called a pseudo-BOM) represents a sub-assembly that is not physically stocked as a separate item. When MRP encounters a phantom BOM, it “explodes through” the phantom — instead of planning a production order for the phantom, it adds the phantom’s components directly to the parent’s material requirements. Use phantom BOMs for logical groupings of components that are always consumed together but never independently manufactured or stocked (e.g., a “hardware kit” that is always part of a larger assembly).

Q: A production order for 100 units of Product A was completed. Standard cost per unit is $50. Actual material cost was $4,800 and actual labor cost was $700. What is the total production variance and how is it classified?

A: Standard cost for 100 units = 100 x $50 = $5,000. Actual cost = $4,800 + $700 = $5,500. Total variance = $5,500 – $5,000 = $500 unfavorable. This can be further broken down into material variance (actual material minus standard material) and labor variance (actual labor minus standard labor), depending on the standard cost breakdown.

Financial Management Module Review

The Financial Management module covers accounting configuration, transaction processing, and financial reporting.

Key Concepts to Review

• Chart of Accounts: Understand account elements (C_ElementValue), account types (Asset, Liability, Owner’s Equity, Revenue, Expense), natural accounts versus dimension accounts, and summary accounts versus posting accounts.
• Accounting Schema: Understand the purpose of C_AcctSchema, GAAP settings, costing level (client, organization, batch/lot), currency, and the role of accounting dimensions (Account, Organization, BPartner, Product, Activity, Campaign, Project).
• Document processing and accounting: Understand how document completion triggers the accounting engine. Know the relationship between source documents (invoices, payments, shipments) and their accounting consequences (Fact_Acct entries). Understand the posting logic for key document types.
• Accounts Payable: Vendor invoice processing, three-way matching (PO, receipt, invoice), payment terms, payment selection, payment generation.
• Accounts Receivable: Customer invoicing, credit management, dunning, payment receipt, allocation.
• Financial reporting: Trial balance, balance sheet, income statement. Understand how iDempiere’s report engine aggregates Fact_Acct data to produce financial statements.
• Multi-currency accounting: Exchange rate types, currency conversion at transaction time, realized and unrealized gain/loss calculation, revaluation processes.

Common Exam Questions (Financial Management)

Q: Describe the accounting entries generated when a vendor invoice is matched to a purchase order and material receipt in iDempiere.

A: When a vendor invoice is completed with a matching PO and receipt: (1) Debit the expense or inventory account for the invoice line amount. (2) Credit the Accounts Payable liability account. If the invoice amount differs from the PO amount (and the PO was the basis for the receipt valuation), a price variance entry is generated: debit or credit the Purchase Price Variance account for the difference. The inventory was initially valued at PO cost upon receipt; the invoice adjusts for any price difference.

Q: What is the difference between realized and unrealized foreign exchange gain/loss?

A: Realized gain/loss occurs when a foreign currency transaction is settled (e.g., a payment is received for a foreign currency invoice). The difference between the exchange rate at invoice date and payment date creates a realized gain or loss that is posted to the Exchange Gain/Loss account. Unrealized gain/loss occurs at period-end when open foreign currency balances are revalued using the current exchange rate. This adjusts the balance sheet to reflect current values but is reversed at the start of the next period. Unrealized gains/losses are calculated by a revaluation process and do not represent actual cash flow differences.

Practice Scenario: Accounting Analysis

Scenario: A company sells goods to a customer. The sales order has 10 units of Product X at $100 each. The product’s average cost is $60 per unit. Tax rate is 10%. Trace the accounting entries through the full order-to-cash cycle.

1. Shipment (Material Receipt from customer perspective):
   • Debit: Cost of Goods Sold $600 (10 x $60)
   • Credit: Inventory $600
2. Customer Invoice:
   • Debit: Accounts Receivable $1,100 ($1,000 + $100 tax)
   • Credit: Revenue $1,000
   • Credit: Tax Payable $100
3. Payment Receipt:
   • Debit: Bank/Cash $1,100
   • Credit: Payment Selection/Unallocated $1,100
4. Payment Allocation:
   • Debit: Payment Selection/Unallocated $1,100
   • Credit: Accounts Receivable $1,100

Gross profit on this transaction: Revenue ($1,000) minus COGS ($600) = $400 (40% margin).

Study Strategies and Time Management

Preparing effectively for the certification exam requires a structured approach.

Study Plan

1. Review all lessons: Re-read each lesson, focusing on the concepts you find least familiar. Take notes on topics that require additional practice.
2. Hands-on practice: Set up a development environment and practice writing model validators, callouts, processes, and event handlers. The coding exercises require fluency, not just understanding.
3. Practice with Garden World: Use the Garden World demo environment to walk through business processes end-to-end: creating orders, completing shipments, generating invoices, processing payments, running MRP, and creating production orders.
4. Study the source code: Read the source code for key classes — MOrder, MInvoice, MPayment, Doc_Invoice, MPPMRP. Understanding how the core code works deepens your ability to extend it.
5. Practice scenarios: Work through the practice scenarios in this lesson and create your own. The ability to analyze a business scenario and determine the correct iDempiere configuration or code is the core skill being tested.

Time Management During the Exam

• Allocate time proportionally to each section’s weight. Do not spend too long on any single question.
• For multiple-choice questions: read all options before selecting. Eliminate obviously wrong answers first. If unsure, mark the question for review and move on.
• For coding exercises: read the entire problem statement before starting to code. Plan your approach (which classes to extend, which methods to implement) before writing code. Leave time for testing.
• Reserve 10-15 minutes at the end for review — check for unanswered questions and re-read your code for obvious errors.

Common Exam Pitfalls

Candidates commonly lose points on the following patterns:

• Confusing model validators and callouts: Remember that callouts fire on UI events (user changes a field) while model validators fire on data events (record save/delete, document processing). Callouts do not fire during programmatic saves.
• Forgetting null checks: In coding exercises, failing to check for null values on optional fields or lookup results causes NullPointerExceptions. Always handle null defensively.
• Incorrect document timing: Using TIMING_AFTER_COMPLETE when you need TIMING_BEFORE_COMPLETE (or vice versa) is a common error. Before-complete can prevent completion (by returning an error); after-complete cannot prevent it but can perform follow-up actions.
• Confusing debit and credit: In accounting questions, remember the fundamental rules: assets and expenses increase with debits; liabilities, equity, and revenue increase with credits. An easy mnemonic: DEALER (Debits increase Expenses, Assets, Losses; credits increase Equity, Revenue).
• Overlooking multi-tenant implications: When writing code, always consider AD_Client_ID and AD_Org_ID. Queries that forget to filter by client may return data from other tenants.

Resources for Further Study

Beyond this curriculum, the following resources support continued learning:

• iDempiere Wiki: The official wiki contains detailed documentation on configuration, development, and administration.
• Source code: The GitHub repository is the ultimate reference. Reading the source code for core functionality teaches patterns and conventions that no documentation can fully convey.
• Community mailing lists: The idempiere-developers and idempiere-users mailing lists contain years of discussions, solutions, and design rationale.
• iDempiere Conference recordings: Past conference presentations cover advanced topics and real-world implementation experiences.
• Practice environment: Maintain a personal iDempiere development environment for experimentation. The best way to learn is by doing.

Certification and Career Development

iDempiere certification positions you as a validated expert in an open-source ERP platform that serves organizations worldwide.

Career Paths

• iDempiere Consultant: Implement and configure iDempiere for client organizations. Requires broad functional knowledge and strong communication skills.
• iDempiere Developer: Build custom plugins, integrations, and extensions. Requires strong Java skills and deep knowledge of iDempiere’s architecture and APIs.
• ERP Architect: Design iDempiere deployments for enterprise-scale organizations. Requires expertise in system architecture, performance, and integration.
• Open-Source Contributor: Build a reputation by contributing to iDempiere core, potentially leading to committer status and influence over the platform’s direction.

Continuing Education

The ERP landscape evolves continuously. Stay current by:

• Following iDempiere releases and understanding new features and changes.
• Participating in community discussions and contributing to the project.
• Expanding into adjacent areas: database administration, cloud infrastructure, business analysis, project management.
• Attending the annual iDempiere World Conference.

Summary

This lesson — and the certification it prepares you for — represents the culmination of a comprehensive journey through the iDempiere platform. You have studied the architecture that makes iDempiere work, the development patterns that extend it, the business processes it supports, and the methodology that delivers successful implementations. The certification exam tests this knowledge through both conceptual questions and practical coding exercises.

Remember that certification is a milestone, not a destination. The most valuable iDempiere professionals combine certified knowledge with real-world experience, continuous learning, and active community participation. Take what you have learned in these 47 lessons and apply it — configure systems, write plugins, solve business problems, contribute to the community, and keep learning.

Good luck on your exam, and welcome to the community of iDempiere experts.

@Component(name = "com.example.CreditLimitValidator",
           immediate = true,
           service = IModelValidator.class)
public class CreditLimitValidator implements IModelValidator {

    private int clientId = -1;

    @Override
    public void initialize(ModelValidationEngine engine, MClient client) {
        if (client != null) clientId = client.getAD_Client_ID();
        engine.addDocValidate(MOrder.Table_Name, this);
    }

    @Override
    public int getAD_Client_ID() {
        return clientId;
    }

    @Override
    public String login(int AD_Org_ID, int AD_Role_ID, int AD_User_ID) {
        return null;
    }

    @Override
    public String modelChange(PO po, int type) throws Exception {
        return null;
    }

    @Override
    public String docValidate(PO po, int timing) {
        if (timing == TIMING_BEFORE_COMPLETE) {
            MOrder order = (MOrder) po;

            // 僅檢查銷售訂單
            if (!order.isSOTrx()) return null;

            MBPartner bp = new MBPartner(order.getCtx(),
                order.getC_BPartner_ID(), order.get_TrxName());

            BigDecimal creditLimit = bp.getSO_CreditLimit();
            if (creditLimit == null || creditLimit.signum() == 0)
                return null; // 未設定額度

            BigDecimal creditUsed = bp.getSO_CreditUsed();
            BigDecimal orderTotal = order.getGrandTotal();
            BigDecimal totalExposure = creditUsed.add(orderTotal);

            if (totalExposure.compareTo(creditLimit) > 0) {
                return "Credit limit exceeded. Limit: " +
                    creditLimit + ", Current exposure: " +
                    creditUsed + ", Order total: " + orderTotal;
            }
        }
        return null;
    }
}

public class UpdateCreditStatusProcess extends SvrProcess {

    private int daysOverdue = 30;

    @Override
    protected void prepare() {
        for (ProcessInfoParameter param : getParameter()) {
            if ("DaysOverdue".equals(param.getParameterName())) {
                daysOverdue = param.getParameterAsInt();
            }
        }
    }

    @Override
    protected String doIt() throws Exception {
        int updated = 0;
        int total = 0;

        String sql = "SELECT DISTINCT C_BPartner_ID FROM C_Invoice " +
            "WHERE IsSOTrx='Y' AND IsPaid='N' AND " +
            "PaymentTermDueDate(C_PaymentTerm_ID, DateInvoiced) " +
            "< addDays(getDate(), -?) " +
            "AND AD_Client_ID = ?";

        PreparedStatement pstmt = DB.prepareStatement(sql, get_TrxName());
        pstmt.setInt(1, daysOverdue);
        pstmt.setInt(2, getAD_Client_ID());
        ResultSet rs = pstmt.executeQuery();

        while (rs.next()) {
            total++;
            int bpId = rs.getInt(1);
            MBPartner bp = new MBPartner(getCtx(), bpId, get_TrxName());

            if (!"X".equals(bp.getSOCreditStatus())) {
                bp.setSOCreditStatus("X"); // 信用保留
                bp.saveEx();
                updated++;
                addLog("Set credit hold: " + bp.getName());
            }
        }
        DB.close(rs, pstmt);

        return "Reviewed " + total + " partners, " +
               updated + " placed on credit hold";
    }
}

@Component(name = "com.example.CreditLimitValidator",
           immediate = true,
           service = IModelValidator.class)
public class CreditLimitValidator implements IModelValidator {

    private int clientId = -1;

    @Override
    public void initialize(ModelValidationEngine engine, MClient client) {
        if (client != null) clientId = client.getAD_Client_ID();
        engine.addDocValidate(MOrder.Table_Name, this);
    }

    @Override
    public int getAD_Client_ID() {
        return clientId;
    }

    @Override
    public String login(int AD_Org_ID, int AD_Role_ID, int AD_User_ID) {
        return null;
    }

    @Override
    public String modelChange(PO po, int type) throws Exception {
        return null;
    }

    @Override
    public String docValidate(PO po, int timing) {
        if (timing == TIMING_BEFORE_COMPLETE) {
            MOrder order = (MOrder) po;

            // 販売注文のみチェック
            if (!order.isSOTrx()) return null;

            MBPartner bp = new MBPartner(order.getCtx(),
                order.getC_BPartner_ID(), order.get_TrxName());

            BigDecimal creditLimit = bp.getSO_CreditLimit();
            if (creditLimit == null || creditLimit.signum() == 0)
                return null; // 限度額未設定

            BigDecimal creditUsed = bp.getSO_CreditUsed();
            BigDecimal orderTotal = order.getGrandTotal();
            BigDecimal totalExposure = creditUsed.add(orderTotal);

            if (totalExposure.compareTo(creditLimit) > 0) {
                return "Credit limit exceeded. Limit: " +
                    creditLimit + ", Current exposure: " +
                    creditUsed + ", Order total: " + orderTotal;
            }
        }
        return null;
    }
}

public class UpdateCreditStatusProcess extends SvrProcess {

    private int daysOverdue = 30;

    @Override
    protected void prepare() {
        for (ProcessInfoParameter param : getParameter()) {
            if ("DaysOverdue".equals(param.getParameterName())) {
                daysOverdue = param.getParameterAsInt();
            }
        }
    }

    @Override
    protected String doIt() throws Exception {
        int updated = 0;
        int total = 0;

        String sql = "SELECT DISTINCT C_BPartner_ID FROM C_Invoice " +
            "WHERE IsSOTrx='Y' AND IsPaid='N' AND " +
            "PaymentTermDueDate(C_PaymentTerm_ID, DateInvoiced) " +
            "< addDays(getDate(), -?) " +
            "AND AD_Client_ID = ?";

        PreparedStatement pstmt = DB.prepareStatement(sql, get_TrxName());
        pstmt.setInt(1, daysOverdue);
        pstmt.setInt(2, getAD_Client_ID());
        ResultSet rs = pstmt.executeQuery();

        while (rs.next()) {
            total++;
            int bpId = rs.getInt(1);
            MBPartner bp = new MBPartner(getCtx(), bpId, get_TrxName());

            if (!"X".equals(bp.getSOCreditStatus())) {
                bp.setSOCreditStatus("X"); // 与信保留
                bp.saveEx();
                updated++;
                addLog("Set credit hold: " + bp.getName());
            }
        }
        DB.close(rs, pstmt);

        return "Reviewed " + total + " partners, " +
               updated + " placed on credit hold";
    }
}