FUNSTOR performance optimization

Suggested

Good afternoon everyone,

I would like to raise a question regarding the performance of the FUNSTOR task in Sage X3, especially in environments with a high volume of items and stock movements.

In our case, we have observed that FUNSTOR generates a very high number of reads, largely because many processes start from the ITMMVT and ITMFACILIT tables. In large databases, this leads to a significant performance impact.

As a reference, in our environment, the FUNSTOR process for a single plant can take up to 6 hours, which considerably limits its execution frequency and operational usability.

Additionally, we have identified that in some of these processes, no filters are applied based on item status (for example, inactive or non-relevant items), which may be unnecessarily increasing the volume of processed records.

We would like to know if anyone in the community has implemented measures to reduce this impact, especially in high-load scenarios.

More specifically:

  • Have you applied optimization strategies (indexes, filters, partitioning, archiving, etc.) that significantly improved FUNSTOR performance?

  • Have you modified or extended the standard logic (entry points, custom developments) to limit the volume of processed records?

  • Have you had to make trade-offs between performance and data consistency?

  • What execution frequency do you consider appropriate for FUNSTOR in this type of environment (real-time, multiple times per day, nightly batch, etc.)?

  • In what type of environments do you consider it really necessary or recommended to run this process (data volume, stock criticality, type of activity, etc.)?

We are particularly interested in real-world experiences in production environments and lessons learned.

Any feedback or technical guidance would be greatly appreciated.

Thank you very much in advance.

Parents
  • 0
    Suggested

    Hi Jordi

    This is a very familiar pain point in large Sage X3 stock environments, and your observations are absolutely aligned with what many production customers experience once item and movement volumes grow beyond a certain threshold.

    At a high level, FUNSTOR is not “just a rebuild” of stock figures. It:

    Re-evaluates stock balances, shortages, and allocations
    Reconstructs internal stock states from ITMMVT, STOJOU, STOLOT, and ITMFACILIT
    Re-applies rules used by availability, WIP, and commitment logic

    Because of this, Sage designed FUNSTOR to be exhaustive rather than selective.
    In a large environment:
    ITMMVT becomes the dominant cost driver
    Reads scale with history depth × number of items × movements per item
    Plants with long operational history suffer disproportionately

    For an in-depth data performance analysis regarding FUNSTOR, we recommend that you contact the center of excellence (COEX [email protected]) for further assistance and recommendations as they work with different customers and might have worked on a similar experience.

    How to troubleshoot slow performance for Sage X3

    Thanks

  • 0 in reply to Tebogo

    Good afternoon everyone,

    First of all, thank you very much for the time dedicated and for sharing your experiences. After reviewing and analyzing the different responses received from the community, I have been able to draw some conclusions that I would like to validate with you.

    On one hand, it seems clear that there are different approaches to addressing FUNSTOR performance:

    • Technical optimization (SQL analysis, indexing, execution plans)

    • Architectural improvements (dedicated batch runtimes, parallel execution by site)

    • And a deeper understanding of the process design itself, which is exhaustive and highly dependent on data volume

    In this context, one of the key conclusions is that the main cost driver appears to be the historical data volume, especially in the ITMMVT table.

    Based on this, I would like to raise a few follow-up questions:

    Why do you consider it necessary to run FUNSTOR multiple times during the day in a Sage X3 environment?
    In other words, what business or technical needs justify such frequent execution?

    • Is it driven by recurring stock inconsistencies?

    • By availability requirements (ATP, commitments, WIP accuracy)?

    • Or by specific operational processes?

    Or do you see it more as a corrective process that should not necessarily be executed frequently unless required?

    Additionally, considering that ITMMVT volume seems to be the main performance driver:

    Beyond technical optimizations such as indexing, what strategies within Sage X3 have you implemented to reduce this volume or its impact?

    For example:

    • Archiving policies for historical stock movements

    • Functional rules to limit the scope of processed items (inactive, obsolete, no recent activity)

    • Adjustments in business processes to avoid unnecessary stock movements

    • Any other practical approaches implemented in production environments

    My objective is to better understand how to balance data consistency needs with system performance in high-volume environments.

    Thank you again for your time and valuable insights.

Reply
  • 0 in reply to Tebogo

    Good afternoon everyone,

    First of all, thank you very much for the time dedicated and for sharing your experiences. After reviewing and analyzing the different responses received from the community, I have been able to draw some conclusions that I would like to validate with you.

    On one hand, it seems clear that there are different approaches to addressing FUNSTOR performance:

    • Technical optimization (SQL analysis, indexing, execution plans)

    • Architectural improvements (dedicated batch runtimes, parallel execution by site)

    • And a deeper understanding of the process design itself, which is exhaustive and highly dependent on data volume

    In this context, one of the key conclusions is that the main cost driver appears to be the historical data volume, especially in the ITMMVT table.

    Based on this, I would like to raise a few follow-up questions:

    Why do you consider it necessary to run FUNSTOR multiple times during the day in a Sage X3 environment?
    In other words, what business or technical needs justify such frequent execution?

    • Is it driven by recurring stock inconsistencies?

    • By availability requirements (ATP, commitments, WIP accuracy)?

    • Or by specific operational processes?

    Or do you see it more as a corrective process that should not necessarily be executed frequently unless required?

    Additionally, considering that ITMMVT volume seems to be the main performance driver:

    Beyond technical optimizations such as indexing, what strategies within Sage X3 have you implemented to reduce this volume or its impact?

    For example:

    • Archiving policies for historical stock movements

    • Functional rules to limit the scope of processed items (inactive, obsolete, no recent activity)

    • Adjustments in business processes to avoid unnecessary stock movements

    • Any other practical approaches implemented in production environments

    My objective is to better understand how to balance data consistency needs with system performance in high-volume environments.

    Thank you again for your time and valuable insights.

Children
No Data