FDMEE support questions, answered clearly.

Oracle FDMEE Support is the ongoing service that keeps the data loads into HFM, Planning and Essbase running every period: mapping maintenance, failed load resolution, new locations and import formats, period and category setup, drill-through repairs, script maintenance, staging table housekeeping, patching and standby cover at month-end. It is distinct from Oracle’s product support, which covers software defects but not your mappings, your sources or your close calendar. Namandla provides it as a managed service with a named senior consultant who knows your integrations.

Because the load is the first step of every close and the one most exposed to change outside the EPM team. The ERP adds a company code, a chart change renames accounts, a source extract changes its layout after an upgrade, and the month-end load fails at validation on the day the consolidation was due. FDMEE skills are scarce in South Africa and often sit with one person. Support exists so that mappings are kept current with the business, failures are resolved while the close is running, and the knowledge of how each source is handled does not walk out of the door.

A typical Namandla FDMEE support scope covers monitoring of scheduled loads and batches; incident response with defined response times; data load mapping changes with validation against prior periods; new locations, import formats and load rules for new entities or sources; period and category mapping for new financial years; drill-through and landing page repairs; Jython and custom script maintenance; staging table retention and purge; user provisioning and location security; patch assessment and application; quarterly health checks; and priority standby during month-end, half-year and year-end. Scope is agreed per client.

Usually. Common findings are like-mappings and multi-dimension mappings evaluated against every record when explicit mappings would resolve most of them, staging tables that have never been purged, event scripts that reload or reconsolidate more than they need to, large files loaded in one batch instead of in parallel, and an ODI agent or database left at installation defaults. A health check measures import, validate and export times per location, identifies the drivers and fixes them in order of impact. A month-end load that took an hour finishing in minutes is a normal result.

A structured review across three layers. Application: locations, import formats, mapping design and volumes, load rules, scripts, check rules and drill-through configuration. Technical: version and patch level against Oracle’s certification matrix, ODI agent and repository health, staging table growth, scheduler and batch configuration, backup evidence. Operational: the month-end load calendar, who maintains mappings, how ERP changes are communicated, documentation and key-person dependencies. The output is a written findings report with prioritised fixes, each with effort and expected effect.

Yes. Namandla provides standby cover at month-end, interim and year-end, with a consultant available to resolve validation failures, mapping gaps, source extract changes, batch failures and drill-through problems while the close is running. Before year-end we roll period and category mappings forward, confirm that every location still validates against the current ERP extracts, check for new company codes and accounts, and test the batches, so the first load of the new year does not fail on something that could have been caught in December.

Yes. Typical improvements are consolidating overlapping mappings, converting long like-mapping chains to explicit or multi-dimension mappings, rationalising locations that duplicate each other, moving manual loads into scheduled batches, adding check rules so reconciliation failures stop the load rather than surfacing in HFM, and scripting the post-load steps. Every mapping change is validated against prior periods so that the loaded totals do not move unless they were meant to. The aim is a month-end load that runs unattended and fails loudly when the business changes.

Yes, that is most of the work. Support covers loads into HFM, Planning and Essbase, movement between them, write-back to the ERP, and, for hybrid estates, loads from on-premises FDMEE into Planning Cloud and FCCS. It also covers the source side: adapter changes after an ERP upgrade, new extracts, new database views through the universal data adapter, and Excel templates for entities without a ledger. Integration failures are usually a source change nobody communicated, so the fix includes putting a change-notification step in place.

Yes. The common projects are an upgrade from FDMEE 11.1.2.4 to 11.2 as part of an EPM upgrade, including ODI repository migration and script review; migration of FDMEE locations and mappings to Data Integration in Oracle EPM Cloud when the target applications move; and re-pointing integrations after an ERP upgrade or replacement. Namandla handles readiness assessment, migration of mappings and rules, script conversion where required, parallel loads to prove that cloud and on-premises results match, and cutover timed around the close calendar.

By keeping the controls that stop bad data at the door in working order: validation that rejects unmapped codes, check rules that confirm totals reconcile to the ledger, mappings reviewed when the ERP changes rather than after a wrong number is published, and drill-through that still works so any figure can be traced. Support also keeps the staging data retained long enough for audit and purged before it slows the loads. Accuracy problems in EPM applications very often begin in the load, and the load is what the service maintains.

Support that works from the close calendar and the ERP change log rather than from incident tickets. In practice that means monitoring scheduled loads so failures are seen before finance sees them, reviewing ERP master data changes each month for codes that will need mappings, rolling periods and categories forward before the year starts, checking staging table growth and patch levels quarterly, and testing restores. It also means telling you when a risk exists, such as a single administrator, a like-mapping that is too broad or an unsupported version, before it becomes a failed close.

Outsourcing makes sense when FDMEE knowledge sits with one person, when mapping changes cluster around acquisitions and ERP changes and are high-stakes, or when the finance systems team also carries the applications themselves. It makes less sense if you have trained administrators who maintain mappings every period and keep documentation current. Namandla’s managed support is designed to work alongside an internal team, taking the specialist and standby work while your team keeps day-to-day ownership, and to hand knowledge back rather than hold it.

Break-fix support responds after a load has failed, bills by the incident and learns your mappings during the call, usually on the day of the close. Managed support knows your sources, locations, mappings and calendar, monitors the loads between closes, keeps mappings current with the business and carries responsibility for the load being ready when finance needs it. Break-fix suits a stable estate with strong internal skills. For a group whose close starts with an FDMEE load, managed support is usually cheaper over a year, because the incidents that happen at month-end are the expensive ones.

By measurable results on the integrations you already own: loads that run unattended, validation failures resolved before the consolidation slot, audit queries answered by drill-through rather than by reconstruction, fewer re-loads and re-consolidations, and mappings that stay current so acquisitions do not turn into month-end incidents. The return is highest where a replacement of the integration layer is being considered mainly because loads have become unreliable; that is usually maintenance debt, and clearing it costs far less than a re-implementation.

Namandla is a South African consultancy whose senior team has supported FDMEE and its predecessors for about two decades, across SAP, Oracle, JD Edwards, Dynamics and file-based sources, and the consultant assigned to your integrations is the one who answers at month-end. We support 11.1.2.4, 11.2 and Data Integration in Oracle EPM Cloud, and we are independent on the on-premises versus cloud question. Where AI can help with mapping suggestions or load checks, we apply it with a person confirming every change. Contact info@namandla.com or 087 188 3388.