IFS Business Logic in Practice: A Worked Example Across Apps 10 and IFS Cloud

In the companion article we covered the conceptual differences between adding business logic in IFS Applications 10 and IFS Cloud. Here, we'll walk through a realistic, end-to-end example to make those differences concrete.

---

The Scenario: Purchase Order Approval Thresholds by Supplier Category

Acme Manufacturing uses IFS to manage purchasing. Their finance team has a new rule:

When a Purchase Order is released, if the total order value exceeds £10,000 and the supplier is categorised as "New Supplier", the release must be blocked and a manager notified to review the order before it can proceed.

This is a common pattern in ERP implementations — a conditional validation that enforces a business policy at the point of a key workflow transition. Let's implement it in both Apps 10 and IFS Cloud.

---

Implementation in IFS Apps 10

In Apps 10, there are two natural approaches depending on the complexity of the rule and the tools available. We'll use the Configuration approach (custom fields + custom events with PL/SQL), since this is what most Apps 10 implementations relied on.

Step 1: Add a Custom Field to the Supplier

First, we need to capture the supplier category. If IFS's standard supplier data doesn't already have a suitable field, we'll add one.

In IFS Enterprise Explorer → Solution Manager → Custom Fields:

1. Search for the Logical Unit SupplierInfoGeneral
2. Add a new attribute using the custom attribute wizard:
   • Attribute Name: SUPPLIER_CATEGORY
   • Type: Persistent (we want it stored in the database)
   • Data Type: Enumeration (we'll create a custom enumeration)
3. Create a Custom Enumeration called SupplierCategory with values:
   • ESTABLISHED → "Established Supplier"
   • NEW → "New Supplier"
   • PREFERRED → "Preferred Supplier"
4. Bind the enumeration to the SUPPLIER_CATEGORY attribute
5. Approve the attribute and the logical unit
6. Publish the logical unit — this adds the column to SUPPLIER_INFO_GEN_TAB in the Oracle database
7. Navigate to the Supplier Information page in Enterprise Explorer
8. Use Custom Objects → Reload Configuration, then the Column Chooser to add the "Supplier Category" field to the page
9. Distribute the layout via Base Profiles so all users see the field

At this point, users can open any supplier record and set the Supplier Category. The data is stored and queryable.

Step 2: Write the Custom PL/SQL Package

The validation logic needs to live somewhere. In Apps 10, the common pattern is a Custom Utility Package — a PL/SQL package written outside of the IFS component model and deployed directly to the Oracle database.

Connect to the Oracle database using a tool like SQL Developer or Toad:

Note the use of IFS's Application_SYS.Set_Completion_Text and Application_SYS.Stop_Transaction — these are IFS framework procedures that surface a user-friendly error message and roll back the transaction cleanly.

Also note the cf1 column reference. In Apps 10, custom persistent attributes were stored in extension columns named CF1, CF2, etc. on the underlying table. This is a fragile detail that meant custom PL/SQL had to be aware of column ordering if multiple custom attributes existed on the same LU.

Step 3: Create the Custom Event and Action

Now we wire the validation into the IFS purchase order release workflow using Custom Events.

In IFS Enterprise Explorer → Solution Manager → Events → Create Event Action:

1. Navigate to List Events and search for PURCHASE_ORDER_RELEASED — this is an Application Defined Event fired by IFS when a purchase order is released
2. Right-click on the event and select Create New Action for Event
3. Configure the event action:
   • Action Description: Acme - Validate New Supplier Threshold
   • Action Type: Execute Online SQL
   • Perform upon Event: PURCHASE_ORDER_RELEASED
   • Enabled: Yes
4. In the SQL Command field, enter:

The :ORDER_NO syntax passes the event attribute (the order number from the triggering transaction) into our custom package.

5. Save the event action

Step 4: Add to an Application Configuration Package

To transport these changes between environments (e.g., from test to production):

1. Navigate to Custom Objects Overview
2. Select the SUPPLIER_CATEGORY custom attribute, the custom enumeration, and the Acme - Validate New Supplier Threshold event action
3. Right-click → Add to Application Configuration Package
4. Create a new ACP named ACME_PO_APPROVAL_VALIDATION with version 1.0
5. Export the ACP as XML
6. Store the XML in your version control system (Git, SVN, etc.)
7. On the target environment, Import the ACP

⚠️ Note: The custom PL/SQL package (AcmePurchaseOrderValidation) is not included in the ACP. It must be deployed to each Oracle database separately — through a SQL script, a deployment tool, or manually. This is a significant gap in Apps 10's lifecycle management.

Step 5: Test

1. Open a Purchase Order where the supplier is set to "New Supplier" and the total exceeds £10,000
2. Attempt to release the order
3. IFS fires the PURCHASE_ORDER_RELEASED event, which executes the Online SQL action, which calls the custom package
4. The package detects the threshold breach, raises Stop_Transaction
5. The user sees the error message and the order remains unreleased

---

Implementation in IFS Cloud

In IFS Cloud, the recommended approach for this kind of business logic is a Customisation — editing IFS source code using Developer Studio. This is more involved to set up initially, but results in properly managed, upgrade-safe code.

Step 1: Add the Supplier Category Attribute

The supplier category field can still be added via Configuration (the IFS Cloud equivalent of Apps 10's custom objects approach). For a persistent field that will also be used in business logic, IFS recommends adding the attribute as part of the Customisation rather than as a Configuration, to avoid cross-layer dependencies.

We'll add it via Customisation in Developer Studio.

In IFS Developer Studio, with a Customisation Project open:

1. In the Build Home, navigate to the SUPP component and locate SupplierInfoGeneral.entity in the model
2. Right-click → Customize This — Developer Studio creates SupplierInfoGeneral-Cust.entity
3. Add the new attribute to the entity:

4. Run Generate to produce the PL/SQL for the entity change. Developer Studio creates the necessary column on the underlying table and updates the relevant views and API packages.

5. Deploy to the development database.

Step 2: Add the Field to the Aurena Client

To surface the field in the Aurena UI:

1. In the Build Home, locate SupplierInfo.client in the SUPP component
2. Right-click → Customize This → creates SupplierInfo-Cust.client
3. Find the relevant group in the client and add the field:

4. Generate and deploy. The field now appears in the supplier record in Aurena.

Step 3: Write the Validation Logic

The business logic lives in the Purchase Order component's projection service (.plsvc) file — the PL/SQL layer that backs the Aurena projection.

1. In the Build Home, locate the purchase order release action in the PURCH component. Find PurchaseOrder.plsvc (or the relevant projection service file)
2. Right-click → Customize This → creates PurchaseOrder-Cust.plsvc
3. Override the release action with the validation:

Key differences from the Apps 10 approach:

• We use Error_SYS.Record_General — the IFS Cloud standard for raising user-facing errors with proper message management (internationalisation, message codes)
• We access supplier_category as a proper named column — not as CF1 — because the attribute was added through the Customisation layer and the code generator created a real named column
• super(key_) delegates to the original IFS release implementation. The validation runs before the standard logic; if it passes, the original flow continues cleanly
• The code is in a version-controlled source file, not embedded as text in a database record

Step 4: Generate and Build the Customisation

4. Generate the project in Developer Studio — this compiles the Marble models and PL/SQL, creating the actual database objects in the development environment

5. Test in the Aurena client connected to the development database:

   • Set a supplier's category to "New Supplier"
   • Create a Purchase Order with that supplier totalling over £10,000
   • Attempt to release — confirm the error appears
   • Confirm orders under £10,000 or with established suppliers release normally

6. When satisfied, build the Customisation deliverable using the Build Home's build tools — this produces the package that will be deployed to test and production environments

Step 5: Deploy and Manage Updates

Deploy the Customisation package to the test Use Place, conduct UAT, then deploy to production.

When IFS releases an update (typically every six months in the evergreen model):

1. Apply the IFS update to your Build Home
2. Open Developer Studio and run the Update Analyzer on your Customisation Project
3. The Update Analyzer will flag if IFS has changed the Release___ procedure in the Core layer — meaning your @Override may need to be revisited
4. Review any flagged items, reconcile your customisation with the new Core version, rebuild, and deploy

This maintenance step is the trade-off for having properly managed, testable business logic.

---

Side-by-Side Step Comparison

---

Summary of Key Differences

1. Where Business Logic Lives

In Apps 10, validation logic sat in custom PL/SQL packages deployed directly to Oracle, with event actions as the bridge between IFS workflow events and your code. The business logic was outside the IFS component model.

In IFS Cloud, business logic sits inside the IFS source layer — in override files that are part of a formal build project. The logic is injected directly into the workflow call chain via @Override, not triggered through a separate event subscription.

2. Fragility of Custom Field References

Apps 10's custom fields were stored in generic positional columns (CF1, CF2, ...). Any custom PL/SQL referencing these columns was inherently fragile — reorder your custom attributes and your code breaks.

IFS Cloud Customisations use named columns generated from the entity model. The reference is stable and semantically meaningful.

3. Deployment Complexity

The Apps 10 approach required two separate deployment steps: ACPs for configuration objects and manual SQL scripts for PL/SQL packages. These could get out of sync.

The IFS Cloud Customisation approach produces a single deliverable package containing everything — entity changes, PL/SQL, client modifications. One package, one deployment.

4. Upgrade Safety

Apps 10 customisations in custom events were relatively upgrade-safe (they were data in tables, not source files), but the custom PL/SQL packages calling IFS APIs could break silently if IFS changed an API signature.

IFS Cloud Customisations use Update Analyzer to surface conflicts explicitly. It's more work upfront, but there's no silent breakage — the build process fails visibly when something needs reconciliation.

5. The Accessibility Trade-Off

The Apps 10 approach was more accessible to functional consultants. Someone with good IFS knowledge and SQL skills could implement the entire example above without a development environment. In IFS Cloud, the Customisation approach requires IFS Developer Studio, a Build Home, and a developer familiar with the Marble modeling language.

This is a genuine trade-off. IFS Cloud's Configuration path (custom events with embedded PL/SQL) can still be used for simpler logic, but for anything that needs to be maintained reliably through the evergreen update cycle, the Customisation path is the right choice — and that path requires a proper developer.

---

Conclusion

The same business requirement — blocking a purchase order release based on supplier category and value — can be implemented in both IFS Apps 10 and IFS Cloud, but the journey looks very different.

Apps 10 gets you there faster with lower technical overhead. IFS Cloud takes longer to set up but produces more maintainable, testable, and upgrade-resilient code. The trade-off mirrors the broader shift from a monolithic on-premises ERP to a cloud-native, evergreen platform.

If your organisation is evaluating the move from Apps 10 to IFS Cloud, take a close look at your existing customisations. The simpler ones (custom fields, event notifications) will translate relatively cleanly to the Configuration path. The complex ones (business logic in custom PL/SQL packages) are worth rebuilding properly as IFS Cloud Customisations — rather than porting the Apps 10 event-action pattern directly. The initial investment in the proper approach pays dividends every time an IFS update arrives.