Oracle EDM Subscriptions: Syncing Metadata Between FCCS and FCGL

Oracle Fusion Cloud Enterprise Data Management (most of us still call it EDMCS out of habit) solves a problem every EPM team eventually runs into: the same metadata (accounts, entities, cost centers) needs to exist consistently in more than one application. Add a cost center in the general ledger and, sooner or later, Financial Consolidation and Close (FCCS), Planning, and Account Reconciliation all need that same cost center too.

Subscriptions are the mechanism EDM uses to keep that metadata in sync automatically. In this article we'll walk through a subscription set up between FCCS and Oracle Financials Cloud General Ledger (FCGL), what happens when a node moves from one to the other, and what to watch for when you're configuring one yourself.

What a Subscription Actually Does

A subscription links a target viewpoint to a source viewpoint. When a change is approved in the source viewpoint, EDM automatically generates a corresponding request in every viewpoint subscribed to it. You can scope a subscription to specific actions, top nodes, or conditions rather than an entire hierarchy, and you can configure it to either:

• Auto-submit: the generated request moves straight into the target viewpoint's workflow without manual intervention, or
• Manually submit: a submitter reviews and completes the generated request before it moves forward.

Because EDM's request-based governance model applies to every subscription-generated request just as it does to manually created ones, changes that arrive through a subscription still go through validation and, if configured, an approval workflow, so an automated sync can't silently push bad data into a target application.

The Setup: FCCS Subscribed to FCGL

In this example, the Account viewpoint in FCCS is subscribed to a general ledger account viewpoint in FCGL (in this environment, named GL_ACCOUNT_HS_CURRENT; your own naming will depend on how the FCGL application was registered). That means any account-level change approved in the FCGL viewpoint automatically generates a request to replicate that change into the FCCS Account viewpoint.

Oracle's official documentation on setting this up, including how Cloud EDM's node and viewpoint model maps to FCGL's value sets and segments, is here: Integrating with Oracle Financials Cloud General Ledger. We're not reproducing Oracle's setup screenshots here (the UI has since moved to the Redwood experience, so the click paths in older screenshots no longer match what you'll see), but the request flow below matches what you'll experience regardless of interface version.

Step-by-Step: What Happens When a New Account Is Added

1. A submitter adds a node in the FCGL (source) viewpoint. In our example, a top-level node named 88888 is added, and the submitter fills in the properties required for that node type: everything the target application will eventually need.
2. The request is validated. EDM checks the new node against the node type's validation rules before it can move forward. If a required property is missing or invalid, the request is blocked here rather than downstream.
3. The request goes to approval. An approver reviews the request and can Approve, Reject, or Pushback it to the submitter for corrections.
4. Once approved, the subscription fires. Because the FCCS Account viewpoint is subscribed to this FCGL viewpoint, EDM automatically generates a new request to add the equivalent node into FCCS. If the subscription is configured for auto-submit, this happens without anyone having to trigger it manually.
5. A node type converter transforms the node on the way in. FCGL and FCCS don't necessarily use the same node type, so a converter maps properties from the FCGL node type to the FCCS node type. In this environment, the converter is configured to prepend an A_ prefix to the incoming account code, so 88888 arrives in FCCS as A_88888. That transformation is defined using the converter's Transform operation, which lets you build an expression (concatenation, prefixing, and similar manipulations) rather than only copying values as-is.
6. A submitter or assignee completes the FCCS-side request. Any properties specific to FCCS that weren't carried over from FCGL get filled in here.
7. The FCCS approver takes action. Same as step 3 (Approve, Reject, or Pushback), and once approved, the node is live in the FCCS hierarchy.

A Note on Node Type Converters

It's worth being precise about how converters are built, since the order trips people up: you start from the node type you're converting to (in this case, the FCCS node type), open its Converters tab, and then select the node type you're converting from (the FCGL node type) to build the mapping. Getting this backwards is one of the more common configuration mistakes we see; Oracle's guidance on the full setup is here: Adding a Node Type Converter.

Why This Matters

Without a subscription, keeping FCCS and FCGL accounts aligned means someone manually re-entering every chart-of-accounts change in a second application: slow, and an easy way to introduce mismatches between consolidation and the general ledger. With a subscription in place:

• Metadata changes only need to be authored once, in the source application.
• Every downstream change still passes through validation and (optionally) approval, so automation doesn't come at the cost of governance.
• Request combination reduces noise: EDM automatically combines target requests when source and target viewpoints are in the same view and share the same assignee, so approvers aren't reviewing dozens of near-duplicate requests.
• A single subscription can fan out to multiple target viewpoints across multiple applications, each with its own node type converter if the target's node type differs from the source's.

Setting Up Your Own Subscription

A subscription is configured once, on the target viewpoint, by pointing it at a source viewpoint and choosing the scope (all nodes, a top node, or a condition) and submission behavior (auto-submit or manual). If you're setting one up between FCCS and FCGL, or any two EDM applications, start with Oracle's official steps at Subscribing to Viewpoints, and make sure any required node type converter is built and tested before you turn the subscription on.

If you'd like help designing a subscription and converter strategy across your EPM landscape (or auditing one that's already in place), CloudADDIE can walk through your specific application setup with you.

Related reading: our overview of Oracle Enterprise Data Management covers node types, viewpoints, and alternate hierarchies in more depth, our walkthrough of node type converters goes deeper on the transform step used above, and our look at validation rules covers the checks every request in this flow passes through.