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: A Purchase Order Release Control by Supplier Risk

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

When a Purchase Order is released, if its governed value exceeds a configured threshold and the supplier's onboarding risk is NEW, release must be blocked until the supplier has completed the required onboarding review and is reclassified.

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

Before adding code, check the standard purchase-order authorisation setup. The IFS source includes purchase-order approval rules, authorisers, amount checks, and release-time authorisation checks. If the requirement can be expressed safely with standard supplier groups and amount-based authorisation, use that route.

For this comparison, assume onboarding risk is a separate customer-owned concept that the standard rule criteria in Acme's Apps 10 update cannot express. We will document an existing configuration-led approach: a custom field, an application-defined event, and a controlled PL/SQL package.

Step 1: Add a Custom Field to the Supplier

First, we need to capture onboarding risk. SUPPLIER_INFO_GENERAL already contains the standard SUPPLIER_CATEGORY attribute in Apps 10, so reusing that name for a different concept would collide with standard semantics.

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: ONBOARDING_RISK
   • Type: Persistent (we want it stored in the database)
   • Data Type: Enumeration (we'll create a custom enumeration)
3. Create a Custom Enumeration called SupplierOnboardingRisk with values:
   • ESTABLISHED → "Established Supplier"
   • NEW → "New Supplier"
   • PREFERRED → "Preferred Supplier"
4. Bind the enumeration to the ONBOARDING_RISK attribute
5. Approve the attribute and the logical unit
6. Publish the logical unit — this generates the Apps 10 custom-field storage/view artefacts, commonly the logical unit's _CFT/_CFV family and a CF$_... exposed attribute; it does not add a generic CF1 column to the standard base table
7. Navigate to the Supplier Information page in Enterprise Explorer
8. Use Custom Objects → Reload Configuration, then the Column Chooser to add the "Onboarding Risk" field to the page
9. Distribute the layout via Base Profiles so all users see the field

At this point, authorised users can open a supplier record and set its Onboarding Risk. 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:

The inspected IFS source confirms the public Purchase_Order_API.Get_Vendor_No and Calc_Order_Total functions and the Error_SYS.Record_General error pattern. It does not contain the often-copied Application_SYS.Set_Completion_Text or Application_SYS.Stop_Transaction calls. Verify every public signature against the customer's exact Apps 10 update before deployment.

The custom-field column is deliberately labelled a placeholder. Confirm the generated _CFV object and CF$_... attribute in the customer's Apps 10 update. The example fails closed when risk is missing; silently swallowing NO_DATA_FOUND would let incomplete supplier data bypass the control. In production, define whether tax/freight is included and make the threshold company/currency-aware.

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 event engine substitutes &ORDER_NO before executing the block; the quotes are required because the order number is a string. :ORDER_NO would be an unbound Oracle bind variable here. In the inspected source, PURCHASE_ORDER_RELEASED is raised from the purchase-order state transition and Execute Online SQL propagates an exception, so the validation can abort that transaction. Confirm the same call order in the customer's Apps 10 update. Keep synchronous validation local and deterministic; do not make release depend on SMTP or HTTP availability.

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 ONBOARDING_RISK 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_RISK_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 (Acme_Po_Risk_API) is not included in the ACP. Deploy its reviewed SQL script through the customer's controlled Apps 10 database-change process before enabling the event action. Manual, undocumented installation is not an acceptable production process.

Step 5: Test

1. Open a Purchase Order where the supplier onboarding risk is NEW and the governed total exceeds the threshold
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 and raises an IFS business error
5. The user sees the error message and the order remains unreleased

---

Implementation in IFS Cloud

In IFS Cloud, first check whether standard purchase-order authorisation, workflow, or approval rules meet the requirement. That is generally preferable to intercepting release. Use configuration/workflow where it can express the control safely, and a source customisation only when the rule must be atomic in IFS and no supported standard/configuration extension point is sufficient. Source is managed and testable—not automatically upgrade-safe.

Step 1: Add the Onboarding Risk Attribute

The onboarding-risk field can still be added via Configuration. For this worked source-customisation path, however, the field and the code that depends on it will share the customer-solution lifecycle. That avoids a source build silently depending on separately transported configuration metadata.

We'll add it via Customisation in Developer Studio.

In IFS Developer Studio, with a Customisation Project open:

1. Search the Build Home for SupplierInfoGeneral.entity and confirm its owning component in the target release. The inspected generated metadata reports ENTERP; do not guess SUPP from the business area.
2. Right-click → Customize This — Developer Studio creates SupplierInfoGeneral-Cust.entity
3. Create the enumeration model and add the attribute to the entity.

Current Developer Studio references define .entity and .enumeration as declarative text models. They are not XML and they do not use projection-style inline entity { ... } blocks. A representative customer-layer enumeration is:

The corresponding entity-layer shape is:

The flags above model an optional public attribute. Let Developer Studio create the exact files, validate the component and naming, and add any target-release code-generation properties rather than pasting the fragment blindly.

4. Run Generate to produce the supported database/server artefacts and review the generated installation impact. Do not hand-add a column to the standard table.

5. Build and deliver to a non-production environment through the supported customer solution route.

Step 2: Add the Field to the Aurena Client

To surface the field in the Aurena UI:

1. Use model search to locate the client that owns the relevant Supplier Information page; names and component placement can differ by release.
2. Right-click → Customize This and use the generated -Cust.client filename; do not infer it from the page caption.
3. Find the relevant group in the client and add the field:

GeneralGroup is illustrative: replace it with the actual target group and let Developer Studio determine whether that element supports an override or requires another supported layer operation.

4. Generate, build, and deliver the change to a non-production environment. Confirm the field appears on the intended IFS Cloud Web page and that only the intended roles can maintain it.

Step 3: Implement the Validation at a Supported Extension Point

Do not assume a PurchaseOrder.plsvc file or a method named Release___ exists. Some older toolchains and examples refer to projection-service .plsvc source, while current base-server references document layered .plsql source. Generated procedure names and signatures vary by target model and release, so use the scaffold Developer Studio creates for that source baseline.

Use this process:

1. In Developer Studio, locate the public purchase-order release/authorisation flow and the supported extension point for the target release.
2. Confirm whether the rule can be expressed by standard authorisation, a workflow, or a customer-owned action without modifying the standard release path.
3. If atomic source validation is justified, let Developer Studio generate the customer-layer .plsql scaffold.
4. Add the smallest validation before the lower-layer release behaviour.
5. Call the lower layer through the generated super(...) point for an override.
6. Use generated entity accessors/public APIs—never direct reads or writes of standard _TAB tables when a supported API/entity contract exists.
7. Raise a stable Error_SYS.Record_General business message.
8. Do not issue a manual COMMIT; the release/action transaction owns commit or rollback.

A generic validation fragment inside the generated package context is:

The surrounding procedure, risk retrieval, governed threshold, and currency/tax calculation must come from the target release's generated source and the agreed control design. The source-modelled attribute has a meaningful generated name rather than an Apps 10 CF1 assumption, and the complete change is version-controlled and built with the customer solution.

If notification is required, separate it from the atomic release guard. Record a durable approval request or event and notify asynchronously. The release transaction should not depend on SMTP or an external HTTP service being available.

Step 4: Generate and Build the Customisation

1. Generate and validate the affected server, projection/client, and PL/SQL sources in Developer Studio. Review the generated database-installation impact rather than editing generated objects directly.

2. Build and deliver the customer solution to a non-production environment through the supported route for that IFS Cloud installation.

3. Test in IFS Cloud Web:

   • Set a supplier's onboarding risk 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
   • Leave onboarding risk blank — confirm the control fails closed
   • Test the company base currency, tax/freight policy, alternate release paths, background jobs, and API calls

4. When satisfied, promote the same reviewed customer-solution artefacts through UAT and production controls.

Step 5: Deploy and Manage Updates

Deploy the customer-solution delivery to the test Use Place, conduct UAT, then promote the reviewed delivery to production.

For each adopted IFS release or service update:

1. Apply the IFS update to your Build Home
2. Open Developer Studio and run the Update Analyzer on your Customisation Project
3. Use Update Analyzer and the source diff to identify changes in the actual lower-layer element/dependencies used by the extension
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 this Apps 10 pattern, validation lives in a controlled customer PL/SQL package, with an application-defined event action as the bridge from the standard release transition. The package is outside the ACP and needs its own governed deployment.

In IFS Cloud, first prefer standard authorisation, configuration, or workflow. If an atomic source extension is justified, its logic belongs in generated customer-layer source and the exact supported call point for the target release. Cloud events still exist; source is not mandatory merely because a rule is complex.

2. Fragility of Custom Field References

Apps 10 custom fields use generated companion artefacts and commonly expose CF$_... attributes. Code is still coupled to generated custom-field metadata and should verify the actual _CFV contract, but it is not based on generic positional CF1, CF2 columns on the standard table.

IFS Cloud source customisations use meaningful names generated from the entity model. That is clearer than guessing a custom-field storage column, but the contract must still be reviewed when the lower-layer entity changes.

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 all-source IFS Cloud route can keep the entity, enumeration, PL/SQL, and client change in one customer-solution delivery. If page configuration, ACP content, workflow definitions, or external services remain part of the design, they still need an explicit transport order; “Cloud” does not guarantee one package.

4. Upgrade Safety

Apps 10 custom-event metadata was generally update-persistent, but persistence is not compatibility. Event timing, payload parameters, page behaviour, and any IFS API called by customer PL/SQL could still change.

IFS Cloud source customisations use Update Analyzer and build validation to surface many conflicts, but semantic changes can still compile and fail only in behaviour. Update analysis and regression tests are both required.

5. The Accessibility Trade-Off

The Apps 10 configuration portion was accessible to functional consultants, but production PL/SQL still required competent development, security review, and a controlled database deployment. In IFS Cloud, the source route requires Developer Studio, the customer-solution build environment, and knowledge of IFS server-model syntax, Marble client/projection syntax, and generated PL/SQL conventions.

This is a genuine trade-off. Use standard approval/configuration/workflow for rules those features can govern safely; use source only when the rule requires a supported atomic implementation and its recurring update cost is justified. A configuration is not automatically unsafe, and source is not automatically the right choice.

---

Conclusion

The same business requirement — blocking a purchase order release based on supplier onboarding risk and value — can be implemented in both IFS Apps 10 and IFS Cloud, but the supported route and delivery lifecycle look different.

Apps 10 can use a published field, confirmed synchronous event, and public API package for a controlled implementation. IFS Cloud adds formal configuration, workflow, projection, source-build, and managed-service boundaries. Maintainability comes from choosing the smallest supported route and testing its real dependencies—not from assuming Cloud source is inherently safer.

If your organisation is evaluating the move from Apps 10 to IFS Cloud, inspect each dependency rather than translating the mechanism literally. Custom fields and notifications may fit configuration; approval controls may now fit standard authorisation or workflow; justified atomic rules may need customer-layer source; external responsibilities may belong behind a governed API. The valuable migration outcome is the smallest supported design with an owned update and regression-test plan.

Technical References

• IFS Developer Studio entity model syntax
• IFS Developer Studio enumeration model syntax
• IFS Developer Studio PL/SQL @Override reference
• IFS Cloud Tailoring Guide