Override vs Overtake: When to Use Each in IFS Cloud

One of the most critical decisions you'll make in IFS Cloud development is whether to @Override or @Overtake a method. Get it wrong, and you're creating a maintenance nightmare that will haunt you through every upgrade. Get it right, and your customisations stay clean, forward-compatible, and effortless to maintain.

This guide cuts through the confusion with clear examples, real-world decision rules, and the upgrade implications that matter.

The Fundamental Difference

IFS Cloud uses a layered architecture to separate standard code (Base, Core) from your customisations (Cust, Ext). When you need to change behaviour, you have two tools:

@Override: Add Code Before or After

@Override lets you wrap the original method. You add your logic before (pre-processing) or after (post-processing) the standard code executes. The original method is still called — you're just extending it.

Key characteristics:

• You must call the underlying layer's code (via super)
• You cannot change logic in the middle of the method
• You take no ownership of the underlying code
• Upgrades are painless — if standard code changes, you benefit automatically

@Overtake: Replace the Entire Method

@Overtake means you replace the entire method with your own version. The standard code is completely ignored. You own all the logic now.

Key characteristics:

• You do not call the underlying layer's code
• You can change anything — the entire method is yours
• You take full ownership of the code
• Upgrades are painful — you must manually merge changes from each release

Why This Matters: The Upgrade Trap

Here's where most teams stumble: IFS Cloud releases new features, bug fixes, and optimisations regularly. If you overtake a method, you don't automatically benefit from those improvements. Instead, you have three painful options:

1. Stay behind and miss critical fixes
2. Manually merge every change with your customisation
3. Overtake again after each upgrade (expensive, error-prone)

With @Override, upgrades are seamless. Your pre/post logic runs on top of the latest, best version of the standard code.

As IFS explicitly states in their best practices: "Use @overtake as a last resort only since when you do this you effectively branch the standard code, creating your own copy of it inside your customization and taking responsibility for keeping this code updated with regards to any changes in the standard code in future releases."

When to Use @Override (The Preferred Approach)

Use @Override whenever you can. These are the scenarios where it works:

1. Adding Pre-Processing Logic

You need to validate or prepare data before the standard method runs.

Example: Validating a purchase order before it's created

2. Adding Post-Processing Logic

You need to react after the standard code executes — e.g., triggering integrations, updating custom tables, or sending notifications.

Example: Notify an external system after an order is saved

3. Overriding Views with Filtered Data

You want to restrict which records are visible or add computed columns.

Example: Show only orders from the user's department

When to Use @Overtake (Only When Necessary)

Use @Overtake only when @Override genuinely cannot solve your problem. These are rare scenarios:

1. Changing Logic in the Middle of the Method

The standard code has a complex flow, and you need to inject logic in the middle — not before, not after.

Example: Rewriting a WHERE clause in a query-based method

2. Commands (Atomic Operations)

Commands cannot be overridden — you must overtake and rewrite them entirely.

Example: A domain command that needs complete rewrite

3. Tree Controls and Complex Structures

Overrides don't work well with tree controls due to their complex, hierarchical nature. You must overtake.

4. Modifying Existing Fields in Lists

If you want to change a field's properties (visibility, editability) in a list or fragment, override adds duplicate fields. Overtake the whole structure.

The Decision Tree

Not sure which to use? Follow this logic:

Can you solve it by adding code
BEFORE the standard method?
├─ YES → Use @Override with pre-processing
└─ NO
   └─ Can you solve it by adding code
      AFTER the standard method?
      ├─ YES → Use @Override with post-processing
      └─ NO
         └─ MUST you change the middle
            of the method?
            ├─ YES → Use @Overtake
            └─ NO → Reconsider your design
               (there might be a better way)

Real-World Maintenance Scenario: The Upgrade Trap

Scenario: You overtook a method to add custom validation. Two years later, IFS releases v25 with a critical security fix in that exact method.

With @Override:

• Upgrade automatically includes the security fix
• Your custom validation runs on top of the secure code
• You're protected immediately
• Zero manual work

With @Overtake:

• Your overtaken method doesn't include the fix
• You don't even know about it until someone discovers the vulnerability
• You must manually review the diff, merge the fix, test, and deploy
• Days or weeks of work, security risk in between

This is why the decision matters. One choice scales smoothly; the other becomes a growing debt.

Real-World Examples: When Each Approach Shines

Override Example: E-Commerce Order Validation

You're building a custom validation layer for orders placed through your e-commerce portal. The standard IFS method creates the order, but you need to:

• Check inventory across multiple warehouses
• Apply custom pricing rules based on customer segment
• Verify credit limits against a third-party system
• Log the transaction to your compliance system

You cannot skip the standard IFS order creation (it updates critical tables, triggers workflows, etc.), but you need to add your checks first.

Solution: @Override with pre-processing

Why override works: You're not changing how IFS creates orders, you're just wrapping it with your business rules.

Overtake Example: Complex Pricing Logic

Now imagine a different scenario: your company has a proprietary pricing algorithm that IFS's standard calculation doesn't support. The algorithm:

• Uses AI/ML scoring based on historical data
• Applies dynamic pricing based on market conditions
• Considers competitor pricing in real-time
• Applies complex discount matrices that IFS views don't support

You cannot pre-calculate and post-calculate your way around this — the IFS standard pricing logic will always run and produce the wrong result.

Solution: @Overtake the pricing method

Why overtake is necessary: There's no way to wrap this logic; you need to replace the pricing calculation entirely.

Practical Tips for Clean Customisations

1. Use Search & Replace for Surgical Overtakes

If you absolutely must overtake, IFS provides a "surgical" approach: overtake using Search & Replace to change only specific code sections rather than the entire method.

This way, if the rest of the method changes in a future release, you only need to adjust your replacement, not the entire method.

3. Version Your Overtakes

If you must overtake, keep meticulous notes about which IFS release your overtake was based on. When you upgrade, you'll need to compare your overtake against the new standard code.

4. Create Test Cases for Overtakes

Because overtakes aren't automatically updated with IFS releases, they need dedicated test coverage. Each upgrade cycle, retest all your overtakes.

5. Minimise the Scope of Overtakes

If you must overtake, overtake the smallest method possible. Don't overtake a complex orchestration method if you can overtake a simpler sub-method instead.

Bad:

Better:

2. Create an Upgrade Impact Map

Before you overtake, create a document listing:

• What you overtook — method name, module
• Why it was necessary — business requirement that override couldn't solve
• What changed — specific logic modifications
• Impact radius — what other code calls this method, what it affects
• Upgrade risk — how likely IFS is to change this method

Example:

Overtake: Calculate_Tax_Amount___
Reason: Standard IFS taxation doesn't support our regional tax rules (2 different tax zones per customer)
Changed: Added logic to determine which tax zone applies based on order delivery address
Impact: Called by Invoice_Creation, Order_Total_Calculation, Reporting views
Upgrade Risk: HIGH (IFS regularly updates tax logic to support new regulations)
Last IFS Update: v24r1 added EU VAT reverse-charge logic (we had to merge)
Next Review: v25r1 expected (changes to carbon tax reporting)

This map becomes your upgrade checklist.

3. Document Your Intentions

Use comment markers to flag where you override or overtake. This helps maintainers understand why you made that choice.

3. Avoid Over-Customising

Before you override or overtake, ask: "Is this really necessary? Does IFS have a standard way to do this?"

Often, IFS provides extensibility points, configuration options, or events that avoid the need for code customisation altogether. Check the documentation first.

4. Test Against Future Releases

Overrides are upgrade-safe, but test them anyway. Overtakes require active maintenance — plan for re-validation after each release.

The Marker Snippet Pattern

IFS provides snippet markers to document your changes for the Update Analyzer tool, which helps flag conflicts during upgrades.

Using these markers helps IFS's upgrade tools identify your changes and alert you to potential conflicts before they become problems.

Key Takeaways

1. Prefer @Override. It's the IFS-recommended approach for a reason — clean, maintainable, upgrade-safe.

2. Use @Overtake only when you must change the middle of the method. If pre/post processing works, use it.

3. Overtakes are technical debt. Every overtake you write is a promise to maintain that code forever, through every upgrade cycle.

4. Upgrades are your friends. With @Override, you get security fixes, performance improvements, and new features automatically. With @Overtake, you get none of them without manual work.

5. Test your design. Before you decide on either approach, ask yourself: "Is there a standard IFS extension point that does this already?" Often there is. Check IFS's exits, hooks, and customisation points before resorting to override or overtake.

6. Search & Replace is your compromise. If you must overtake, use surgical search-and-replace overtakes to minimise the maintenance burden.

7. Document why. Whether you override or overtake, document why you chose that approach. Future maintainers (including yourself) will thank you.

The Upgrade Lifecycle: What Happens With Each Approach

Let's walk through a realistic scenario: IFS releases v25 with changes to the Calculate_Line_Price___ method.

If You Used @Override:

1. Day 1 (Upgrade released): You upgrade your IFS instance
2. Day 2: Your override automatically runs on top of the new, improved IFS code
3. Day 3: You test to confirm your pre/post logic still works correctly
4. Day 4: You're done. Total effort: ~4 hours testing
5. Benefit: You automatically get any performance improvements, security fixes, or new features IFS added

If You Used @Overtake:

1. Day 1 (Upgrade released): You download v25 release notes
2. Days 2-3: You read the 50-page changelog, identify changes to Calculate_Line_Price___
3. Days 4-6: You manually compare the new IFS code against your overtaken version
4. Days 7-8: You manually merge changes — this is tedious and error-prone
5. Days 9-10: You retest the entire customisation
6. Days 11-12: You deploy and verify in production
7. Total effort: ~80 hours of work
8. Risk: You might miss a subtle change, introduce a bug, or break something unexpected

This is why @Override is preferred: Eight hours vs. eighty hours. One decision, made once, compounds over years.

If you have just five overtakes across your customisation, that's the difference between 40 hours and 400 hours per upgrade cycle. Over a 5-year contract, that's:

• @Override: 40 hours total
• @Overtake: 2,000+ hours (equivalent to 1+ full-time developer)

The cost of choosing wrong scales exponentially.

Closing Thought

Every @Overtake is a fork in the road. You're creating a branch of IFS code that's now your responsibility to maintain, integrate with, and upgrade forever. Sometimes it's necessary. Most of the time, it's not.

Choose wisely. Your next upgrade depends on it.