Recent Content
Matrix Consolidation: Eliminating Beyond Legal Entity
Purpose of the document To goal of this document is to share our experience in designing for a matrix consolidation requirement, as well as to drive discussion on the topic. What we mean by “matrix consolidation” Matrix consolidation is a term commonly used when finance teams want to prepare their management & statutory financials concurrently. This prevents the need to maintain separate scenarios and processes in the system. It will usually involve running eliminations on something more than just legal entity. In OneStream this can mean using a user defined dimension as part of the elimination process. The Requirement A common use case is to run eliminations between Profit Centres or Segments. Whilst inter-profit-centre eliminations will be used as the example in this document, it is not the only potential use case. The requirement we will attempt to solve for is that the customer wants an elimination to only occur at the first common parent in both the Legal Entity and Profit Centre hierarchies. First let’s look at the two broad ways in which this can be achieved. ENTITY DIMENSION OR USER DEFINED (UD) DIMENSION So, there is a requirement to do eliminations on a level of detail below the legal entity/company code level. The example we will use in the section is where the customer wants to generate eliminations between Profit Centres (PC). You have two main options on how to tackle this, outlined in the following two sub-sections. OPTION 1: ENTITY DIMENSION Include this Profit Centre detail in your entity dimension as base members. These will be children of the legal entity members. OPTION 1: ENTITY DIMENSION Include this Profit Centre detail in your entity dimension as base members. Pros Cons Business Logic · No additional Logic required to get eliminations running by Profit Centre. · Impacts consolidation performance more than option 2 in a typical setup, due to multiplication of members in the entity dimension (i.e. more data units) that are to be consolidated. Exact impact need to be analysed in each project. · If you move a PC in the entity hierarchy, you will need to reconsolidate all history. Dimensions · Uses fewer UD dimensions than option 2. · Generally, only appropriate when Profit Centres are unique to entities, since otherwise they will need to be duplicated for each entity. · Can end up with a very large entity dimension · To achieve some reporting, alternative entity hierarchies (and therefore additional consolidations) may be required. · Often leads to creation of additional “dummy” or “journal” Profit Centre entities to contain data that doesn’t need to be captured by Profit Centre (e.g. Balance Sheet Data). This creates even more entities to be consolidated! · When Profit Centres are not unique to entities, shared Profit Centres will create lots of duplicate entities and should be avoided. · Less flexible since profit centres need to be created & moved within the entity hierarchy. Workflows · If the responsibility structure (and therefore workflow design) is by Profit centre, then can make workflow design/build better. · If the responsibility structure is not based around Profit Centre, more entities will need to be assigned and considered in workflow design. · Makes Profit Centres the basis for everything where data is stored, processed and locked. Reporting & Matching · May align with the way it was done in legacy systems, so users are familiar with the approach. · Standard IC matching reports will work for Profit Centre matching (although this requirement is less common from our experience). · Out-of-the-box matching will now only be at PC level. Legal Entity matching will require custom reporting. · Alternative entity hierarchies (and therefore consolidations) may be required to achieve some reporting. · Execution of consolidation required to see legal entity level data (as they will be parent entities) Security · Native using the entity dimension. · Requires maintenance on a Profit Centre level even if not required on that level. OPTION 2: USER DEFINED DIMENSION Create a Profit Centre dimension in a UD. OPTION 2: USER DEFINED (UD) DIMENSION Include the Profit Centre detail in a User Defined Dimension Pros Cons Business Logic · Logic can be customised to specific requirements. · Does not add additional members to the entity dimension (i.e. data units), which is beneficial for consolidation performance in a typical setup. · Running a consolidation, will run a statutory and management consolidation in parallel. · Requires additional development time for business logic if not part of a starter kit. Dimensions · A cleaner entity dimension to support legal entity and group reporting. · Matrix view of consolidation can be created (e.g. with entities in rows and Profit Centres in columns) · Can be combined with extensibility if Profit Centres aren’t applicable to all entities/divisions. · Requires the use of two UD dimensions (one for Profit Centre and another for PC counterparty). This is discussed later. Workflows · Often more closely aligns with the responsibility structure for Actuals (by legal entity). Reporting & Matching · Standard IC matching reports will support legal entity matching. · Consolidation not required to view total legal entity values (pre-elimination data) · Custom IC matching reports may be required for Profit Centre matching. This is less common as a requirement. Security · Native using the entity dimension if security is driven by Legal Entity. · Requires slice security (via Cube Data Access security) if required at Profit Centre level (can impact reporting performance if security is complex). Other Design Considerations Data quality of matrix counterpart – Remember, all intercompany data from the source system needs to be sourced for all matrix dimensions. It will negatively impact user experience if this data is not readily and accurately available in the source system (lots of manual input will be required). Stability of the matrix dimension – This is to say, in your situation, will the Profit Centre hierarchy change regularly with relationships changing? This requires significant consideration in the design phase. Some discussion points are included in a later section. New or existing application – The choice of solution may depend on whether this is a new implementation or an addition to an existing one. It will likely be easier to add a new UD to an existing application rather than re-develop the entity dimension! Performance – Common design considerations of performance, data unit sizes, number of data units etc. apply. Elimination vs. Matching – Remember that just because a customer wants their eliminations to happen on PC doesn’t mean that they need to do their month end intercompany matching at this level. It’s important to clarify this as two separate requirements during gathering. Workflow – Ensure you consider the responsibility structure of the organisation as this will have a big impact on the decision. If the true process (loading, locking, calculating & certifying the data) is by Profit Centre, then this could be a good justification for using the Entity dimension (option 1). However, it’s much more typical that these are based on legal entity for Actuals, making a UD solution (option 2) more appropriate. Option Overview The best approach will vary depending on the specific requirements, but the above gives some common indications of the benefits & drawbacks of each approach. Adding members to the entity dimension creates additional overhead during consolidation since the system must run the data unit calculation sequence (DUCS), consolidate and check the status on each entity member. Therefore, including profit centre in the entity dimension will often be slower than using a UD (in the presence of typical data volumes, exceptions always apply!). Regardless of the approach, remember that with the default eliminations always occur at the first common parent in the Entity dimension. If the client wants something different, then you would be looking at a “non-matrix” solution (i.e. separate cubes for statutory and management). But that is a different topic… Since option 1 mostly uses system-default logic for processing and eliminating the data, the setup is mostly straight forward. Therefore, the rest of the document focuses on how to design for Option 2, using a user defined dimension to contain this detail and run eliminations. Out of the Box - view of Eliminations It is worth stating that just because a client says “we need the eliminations to run by profit centre” doesn’t mean that they need to implement a full matrix consolidation solution. If they don’t need the profit centre elimination to happen at the first common parent in the PC hierarchy, then the out of the box eliminations will suffice as you can report the eliminated data simply by selecting the correct combination of members (Origin, PC, etc.). For those less familiar with the topic, let’s just take a moment to set up a simple example that shows the default behaviour of eliminations in OneStream. We have a Profit Centre dimension in UD1, and an entity dimension for the legal entity members as follows (all entities are using USD only & are 100% owned, for the sake of a simple example): There is an intercompany transaction between the legal entities Manchester & Houston: Within Manchester it is captured within the Finance PC, and within the Houston Sales PC. When out-of-the-box eliminations are run, we will see the following results (eliminations in red, consolidated results in the blue box): The eliminations occur at the first common parent in the entity dimension (in this case the first common parent is the Main Group). In the UD1 the eliminations happen on the same member as the original data, so at the group level we still see the plug amounts by Profit Centre. If we zoom into the Profit Centre dimension (UD1) at the top Main Group reporting entity member, we see the following, where 100 is the aggregated difference on the plug account of the two base level Profit Centres Finance1 and Sales1: Matrix Consolidation - View of Eliminations Now let’s imagine we have the same setup but want to apply matrix consolidation. We have the same data, but now we are capturing the Counterpart Profit Centre for each transaction: Notice how in the below screenshot our eliminations will be happening on a new “elimination member” within UD1, rather than the member the data sits on (highlighted in the green boxes below; the required elimination members are discussed further in the next section on the setup). The member where the elimination occurs represents the first common parent of the PC & Counterparty PC in the hierarchy (in our example this is the “Top_PC” member in UD1). Again, if we look at this result in more detail at the Main Group entity level, you can now see that within the UD1 hierarchy, the elimination doesn’t occur until the first common parent in the UD dimension. So, at “Top_PC” the data is eliminated, but at descendant UD1 members, it is not (e.g. Admin_PC, Finance_PC, Sales_PC). Note that we have the same result at the Top Profit centre and Group entity, but the way we get there is different. Now that we understand the situation we are trying to tackle, let’s look at the setup used in this example. Setup The following items are configured in our matrix consolidation example. Entity No changes are required to the entity dimension for matrix consolidation. Account No changes are required to the account dimension for matrix consolidation. We will use the same plug accounts. UD1 – Profit centre Some additional elimination members are required in our UD1 as follows. Whilst UD1 is used in our example, the usual design decisions apply to which UD you use. These new elimination members will be required at every point an elimination may happen, so you can see that this can potentially add a large number of members to your existing hierarchy. A common naming convention is often used to allow the system to derive where to post the elimination. In this case you can see it is the parent member name with a prefix of “Elim_”. Alternatively, you could use text fields to store this information. Either way, the logic will rely on this being updated accurately and consistently. Tip: Ensure your consolidation logic provides helpful error messages if it finds that an elimination member does not exist or is misconfigured. UD7 - NEW Counterparty PROFIT CENTRE A new dimension is needed to capture the counterparty Profit Centre information. Like the Intercompany dimension in OneStream, this can be (and almost always is) a simple flat list of the base counterparties. All relevant intercompany data now needs to be analysed by this dimension so input forms & transformation rules will need updating. In data models where (almost) all UDs are already in use, this element can be challenging and requires consideration. Whilst UD7 is used in our example, the usual design decisions apply to which UD you use. Remember that this dimension is simply used to capture the counterparty so if your design is already using lots of dimensions then you may be able to combine this with other supplementary data, or maybe even use UD8 (although this will need additional consideration in your dynamic reporting design). Tip: Consider how this dimension will be maintained going forwards as it will be important for the logic that all members exist with the same naming in this counterparty dimension. Consider if the counterparty dimension could/should be automated to align with the main PC dimension. Business Logic Since, unlike the entity dimension, all parents in a UD are calculated on-the-fly this approach will require additional eliminations to be calculated. You will need to store your new matrix consolidation logic somewhere; in our case it is a business rule attached to the cube, but it could also be attached to a member formula: Tip: You DO NOT need to switch on custom consolidation algorithm on the cube to achieve a matrix consolidation result. Always consider the wider requirements & design. Reporting Custom reports will need to be developed to allow users to do IC matching and report on the resulting eliminations meaningfully. If the customer already does their elimination like this, they should have existing specifications that can be designed for. But if not, end users will need to understand Matrix consolidation when they build their own reports/Quick Views or just run LE-based reports with “Top” for Profit Centres. Tip: You can use Data Set business rules to help you efficiently gather your data for interactive dashboard & reports. Business Logic Consolidation Algorithm When a matrix consolidation requirement exists, it has been commonly observed that consultants will switch on the Custom Consolidation algorithm on the relevant cube(s). However simply because this stores the Share data, this has a negative impact on consolidation performance, and database size. Before you reach for the Custom algorithm though, I would recommend considering calculating the matrix elimination adjustments during the calculation pass of C#Elimination, within a UD member (potentially within your data audit dimension). This will allow you to remain on the Standard or Org-by-Period algorithm and within this member you can update the standard eliminations with the PC detail. Of course, you may have other requirements that lead to you using the Custom algorithm, in which case the approach for matrix eliminations can be determined in the context of the overall design. Tip: Consider whether matrix eliminations are required for all processes & scenarios and ensure it is only running on those where it is truly required. Useful Snippets The general approach for writing a matrix consolidation rule is to check that the elimination only occurs at the first common parent – other than that it will follow standard OneStream rule writing techniques such as using data buffers. The following functions can be useful (comments correct as of version 8.5): Function Comment api.Members.GetFirstCommonParent() You will want to use this function to check both the entity and profit centre parents to see if they’re common to the IC or counterparty member. api.Members.IsDescendant() Note that this doesn’t check whether a descendant has a consolidation percentage greater than zero. So, if doing org-by-period this may need additional consideration. api.Entity.PercentConsolidation() Useful for checking whether entity is being consolidated. Ensure you only pass valid parent/entity combinations into the function. Example rule Attached to this paper you will find a sample rule that can be used as a starting point to implement matrix consolidation. Disclaimer: The provided rule is an example only, and its purpose it to demonstrate an approach that can be taken. If used as a starting point, then all care should be taken to adapt and thoroughly test it before implementation. Updates may be made, without notice, to the example in future. Whilst there are arguably different ways to approach this, the example takes the following approach: Retrieves a data buffer of the system generated eliminations. Reallocates the elimination (both IC & Plug account entry) to the correct PC. Reverses lower-level eliminations from current eliminations (without this step the process will repeat at each parent after the first common parent). Clears the system Elimination as “No Data”. Save Results. This should be assigned to the cube when using the standard or org-by-period consolidation algorithm. It reallocates the out-of-the-box eliminations to the relevant UD member. With some quick reconfiguration of the dimensions & names referenced in the rule, it should work with the setup described in the previous section. org-by period in the UD With regards to matrix consolidation, I have previously been asked the following question: “What happens to the eliminations if we change our Profit Centre structure?” Well in our Entity dimension, we have built in tools to handle org-by-period, so that entities can have relationship properties vary by time period. Data is also stored on parent entities which aids in this org-by-period. Within our UD, no such functionality exists, so if I move a member, that member is moved for all history. If I duplicate a member, the values are duplicated (depending on the aggregation weight of course, but keep in mind that this cannot be varied by time!) So how can we approach this is when a Profit Centre needs to change parents one month: Change the main hierarchy – The old view will no longer be visible. The added complexity is that the eliminations for prior periods will occur in the “wrong” place in the UD hierarchy from a historical point of view unless a consolidation is rerun on all those periods. Of course, if you rerun the consolidation on prior periods, then all your results will change (although not at the top level provided nothing else has changed). This implies that the elimination will correctly display the elimination after the change; Historical data will not be kept for the re-consolidated periods. Create alternate hierarchies (e.g. Top_2023, Top_2024 etc.) – New hierarchies can be created, with unique parents that will allow the old hierarchy to be preserved. As with the first option, re-consolidation of prior periods will be required to view historic data in the same format. However, if the data is only required in the new format going forwards then re-consolidation of prior periods can be avoided. Tip: For every alternate hierarchy in which you run your matrix eliminations, the eliminations will be “duplicated”. Therefore, your business logic should allow you to configure, by time period & scenario, which hierarchies are eliminated to ensure only necessary calculations are run. This could be done, for instance, through tags on text fields of the members. Whilst not such a common scenario, it is a consideration worth making during the requirements gathering & design.Question: Is there any security options to limit a user's ability to submit data using excel?
Answer Submitting data via excel will respect the security model set up in OneStream. So consider typical security setup. Also consider using constraints to manage "valid" data intersections. Inputting data via set cell will get tracked in the audit logs, however, clearing this data can be problematic if you wish to clear all out all submitted cells. Rather than using set cell, another option is to set up an excel import which would go through stage and allow for clearing of the data set. There is a pending enhancement request to have an option available to restrict some users from submitting via excel. Source: Office Hours 2020-7-2 - Partner Enablement863Views5likes3CommentsGovernment Community Cloud v9 Upgrade
OneStream is preparing to release version v9 for our Government Community Cloud customers. This document is a guide to the v9 upgrade process. A v9 upgrade is identified as an upgrade from a pre-v9 version to a v9 version. The designated FedRAMP authorized platform release will be v9 which will be made available to GCC customers later this year. Process Overview: The v9 upgrade has infrastructure and software changes that impact applications and integrations. We will migrate from your existing infrastructure to the new v9 architecture. To prepare our customers for this process, we are providing the pre-requisites for upgrade in advance of the release. See Pre-requisites heading below. In the coming months, GCC customers will be asked to submit a Software Upgrade request in ServiceNow. When the upgrade request is submitted, it will open a Support Case to capture the outputs of the items in the Pre-requisites section below. You will be notified when this is available. Once the pre-requisites are submitted, a OneStream project manager will meet with you to plan a timeline of activities. They will be assigned to the Case, available to meet and assist throughout the process. We will provide a mirrored v9 instance for configuration and testing before your go-live. An application copy is made from your pre-v9 instance to your mirrored v9 instance. The configuration and testing period is timeboxed to 2-3 weeks. The scope of work for the test instance is configuration (for example, SIC setup or business rule compilation updates) and functional testing. We will have you compile your business rules in v9 to determine if there are any new errors resulting from the more stringent .NET 8 compiler. Experts from OneStream will be available via the Case to assist. You should also test all functionality that may not be discovered via business rule compilation. During testing, keep a log of any updates you made to the v9 test instance to remediate issues. When testing is completed, we will schedule your go-live. This is a 4–48-hour process (you will be given a more precise estimate following a database size analysis) of downtime where we copy your live databases to the v9 instances. Weekends and evenings are available. As a final step, you will re-apply the updates discovered during testing, referencing the list you generated. After go-live, your pre-v9 instances are no longer accessible; you will be live in v9. Reference: Plan of Action: GCC v9 Migration Pre-requisites In advance of the v9 release, OneStream will open v9 in the Software Upgrade service catalog. When a v9 Software Upgrade request is submitted, it will open a Case called Cloud Migration Readiness that includes intake forms for the pre-requisite action items described below. We have attempted to put together a comprehensive list of all impacts, but given the customizable nature of OneStream, there may be additional impacts uncovered in testing. We recommend you begin work on these pre-requisite items now. If additional assistance is required before the Cloud Migration Readiness Case can be opened, please open a Case. Please note that these pre-requisites are based on expected approvals for our GCC program. The 3PAO assessment is pending. 1. OneStream IdentityServer Customers upgrading to Platform v9 will be migrated to OneStream’s modern IdentityServer OIS authentication technology. Your identity provider continues to be supported, but a change on our side requires that your IT create or edit (depending on identity provider – see Configuration Guides below) the authentication configuration for each OneStream instance. Pre-requisite steps: Complete any necessary technical reviews by your IT Have your IT configure the new authentication configuration for each of your OneStream instances, referencing the Configuration Guide below per your identity provider and protocol. (See Configuration Process Detail below.) Submit the values gathered in the form of the last page of the Configuration Guide to us via the ‘Authentication’ action item in your v9 Cloud Migration Readiness Case, once available. Configuration details: Provide your IT with the appropriate Configuration Guide, per your protocol and identity provider. Your IT will need site names as input. Your site name is [sitename].onestreamcloud.com, per instance. For DoD customers, your sitename is [sitename].onestream.mil. Additionally, because we are providing you with a duplicated instance for testing, configure [sitename-temp].onestreamcloud.com for each instance. This will ensure you are prepared to access both your testing instances and your final instances after go-live. Example: o Your site names are ‘govcustomer’ and ‘govcustomer-test’. o The sitenames to configure for v9 are ‘govcustomer’, ‘govcustomer-test’, ‘govcustomer-temp’, and ‘govcustomer-test-temp'. We recommend taking a screenshot of each redirect URL and attaching it to Authentication action item submission. This reduces the risk of error and aids troubleshooting. NIPR NET customers will also require a new CSR to be generated for the duplicate Production. This will be provided on your Migration Readiness Case , once available. Configuration Guides: Open ID Connect OIS Entra ID OIS Okta OIS PingFed OIS SAML (with any identity provider) Reference: General documentation Identity and Access Management Guide Note: disregard the section about configuring within OneStream; for our upgrade purposes, we require it in advance of the instance creation. Use the appropriate Configuration Guide below.) For further consultation, open a Conversation on the Cloud Migration Readiness Case. If it is not yet available, open a Case. 2. Smart Integration Connector Smart Integration Connector (SIC) establishes secure connectivity between OneStream Cloud and data sources in your network without a VPN connection. With SIC, you can create and manage network data source integration using OneStream administration interfaces and locally manage database credentials and ancillary files. SIC transition is a requirement for v9 upgrades for several use cases. Use cases for SIC Transition: Customers who are using a Virtual Private Network (VPN) to establish data connectivity between a OneStream cloud instance and a local data source. VPN’s will not be supported with v9 or higher. Customers referencing drivers hosted by OneStream. Drivers being hosted on OneStream servers will not be supported with v9. Examples: ODBC, OLEDB (Oracle), Snowflake, Teradata, Netsuite, SAP, JD Edwards Customers who are utilizing DLL’s. DLL’s being hosted on OneStream servers will not be supported with v9. Pre-requisite steps: Complete any necessary technical reviews by your IT Create the SIC Server (or be ready to deploy it in short order) Install the SIC v9 Local Gateway on the server. You can open a Case to request it securely Submit the ‘Data Connections’ action item in your v9 Cloud Migration Readiness Case, once available. Reference: Smart Integration Connector Guide For further consultation, open a Conversation on the Cloud Migration Readiness Case. If it is not yet available, open a Case. 3. Solutions & Business Rule Changes There are several substantial changes in v9 that impact business rules and Solutions. To prepare for these changes, we recommend that you upgrade to v9 compatible Solutions in advance of migration testing. The process includes multiple application copies from your pre-v9 instance (at initial data load and go-live.) If they are not upgraded in the pre-v9 instance, you will need to upgrade them each time your application is copied to v9. Upgrading in advance reduces risk and complexity. You will compile your business rules in the v9 testing instance to uncover errors, if any. We will have OneStream experts available via the Conversation feature on the Case to assist. Many customers choose to leverage a consultant for this work. Pre-requisite steps: Review Impacted Solutions List, below. Upgrade to any compatible versions in your pre-v9 instance, ahead of the v9 upgrade. Compile your business rules in your pre-v9 instance. We will ask for this on the ‘Customer Specifications’ item of the upgrade Case, when available. The purpose is to rule out any existing errors; we want to focus our efforts on v9. Prepare a list of your Solutions and their current versions. We will ask for this on the ‘Customer Specifications’ item of the upgrade Case, when available. Reference: Impacted Solutions List (note: may need its own community post as right now it’s an Excel doc) Business Rules & Workspace Changes in v8+ For further consultation, open a Conversation on the Cloud Migration Readiness Case. 4. OneStream IP Address Changes The IP addresses of your instance will change with v9. This has potential impacts you can prepare for. We have attempted to put together a comprehensive list of all impacts, but given the customizable nature of OneStream, there may be additional impacts uncovered in testing. Pre-requisite steps: If you have non-VPN web integrations such as API or SFTP, you may need to account for new additional OneStream IP’s in the relevant system. If you can allow your domains in the relevant system instead ([sitename].onestreamcloud.com), we recommend this. Otherwise, we will provide the new Application Gateway IP once the v9 instances are built at the start of the active migration process. If your IT has a strict outbound allow list, for example Cisco Umbrella, ZScaler, or similar products, you may not be able to access the new v9 test instance until they allow it. To prepare for this, review with your IT and ensure for all your site names ([sitename].onestreamcloud.com) that sitename and sitename-temp have been allowed in relevant systems. This will help to ensure that you can access all test instances and live instances. Cloud Note: Integrations using VPN’s are not accounted for here as they will be replaced by Smart Integration Connector. Reference: For further consultation, open a Conversation on the Cloud Migration Readiness Case. If it is not yet available, open a Case. 5. .NET 8 Desktop Runtime .NET is the development platform used by OneStream to build the Platform. Prior to v9, OneStream used versions of .NET referred to as .NET Framework versions. The v7.x Platform release used .NET 4.8. OneStream Platform Release 8.2 or later requires Microsoft .NET 8. Pre-requisite steps: Install .NET 8 Desktop Runtime for all users who will be using the Windows Client*, or prepare to install it in short order https://dotnet.microsoft.com/en-us/download/dotnet/8.0 * v9 provides a browser client for end user functionality. Users working solely with the browser client do not need the .NET Desktop Runtime installed. Reference: For further consultation, open a Conversation on the Cloud Migration Readiness Case. If it is not yet available, open a Case. 6. REST API There is a potential impact to REST API, but the scope has not been determined yet. For now, determine whether you utilize the REST API as your preparedness item. We will share more information when we have it.85Views0likes0CommentsLearn about ESG Reporting and Planning on the new episode of The OneStream Podcast!
On this edition of The OneStream Podcast Andrea Tout, from OneStream's product management team, joins Peter Fugere to talk about our new ESG Reporting and Planning solution. The two discuss how this pre-built solution is helping customers align ESG reporting with financial reporting and planning to deliver rapid and actionable insights to internal and external stakeholders. In addition to helping customers manage the complexities of ESG reporting requirements, it allows them to take finance further by proactively planning, measuring and managing the impact of ESG initiatives across the enterprise through our unified platform.New Episode of Tech Talks After Hours Available for Passport Subscribers
Join Jerome Marcq, Sam Eburn, and Tom Linton as they continue demonstrating how to build no code, collection type Dynamic Dashboards in this follow up to January's live edition of Tech Talks, No Code Dynamic Dashboards! This episode of Tech Talks After Hours is available exclusively through a Passport subscription. https://onestream.thoughtindustries.com/learn/video/tech-talks-after-hours-no-code-dynamic-dashboards-pt-2Now Available: the OneStream Certified Specialist (OCS) Reports and Dashboards Exam
OneStream Global Education Services is excited to announce the OneStream Certified Specialist (OCS) Reports and Dashboards Exam is now available for registration. Exam Description This exam is intended for individuals who have experience as an Administrator with OneStream and built OneStream reports and Dashboards. It will test candidates' knowledge in Workspaces, Dynamic Reporting, Cube Views, Spreadsheets, Dashboard Components as well as other reporting components. Exam Description This exam is intended for individuals who have experience as an Administrator with OneStream and built OneStream reports and Dashboards. It will test candidates' knowledge in Workspaces, Dynamic Reporting, Cube Views, Spreadsheets, Dashboard Components as well as other reporting components. Delivery Type Remote Proctored Availability Customers Partners Employees Who Should Take This Exam? This exam is intended for anyone who has 1-year experience being an administrator for OneStream, 6-months experience building reports and dashboards and has knowledge in areas of Accounting, Finance, and/or Information Technology. Prerequisites Prior to taking this exam, the following courses are recommended: OneStream Essentials: Building Basic Reports OneStream Essentials: Building Dashboards OneStream Essentials: Getting Started with OneStream Exam Details Live, remote proctored, cloud-based environment Exam Duration: 2.5 hours Number of Questions: 60 multiple-choice items, 6 performance-based tasks Languages: English Exam Price: $1000 USD Digital Credential Upon passing this exam a digital credential will be issued. Important Links How to Register: Exam Registration Guide Exam Study Guide: OneStream Certified Specialist Reports and Dashboards Study Guide46Views0likes0CommentsRegister now for the March Live Edition of Tech Talks!
Explore the ultimate in dynamic dashboards as Jérôme Marcq and Sam Eburn join Tom Linton and Matt Kerslake to demonstrate how to convert embedded dynamic repeater dashboards into fully dynamic dashboards for lights out flexibility! Infinitely extensible! Register now! https://www.onestream.com/events/tech-talks-dynamic-dashboards-rules-assemblies/Customer Call to Action Banner Messages in Service Now
OneStream thanks all customers for their diligence in embracing the technology modernization of v8+ Platform versions. As for Platform v8, OneStream is using .NET 8 to drive its high-performance platform. The v8+ platform employs modern self-service technologies for authentication (OIS) and data integration (SIC). Upgrades to Platform v8+ are in full force, and OneStream is using ServiceNow banner messaging to bring attention to customer-specific upgrade related actions. If you have an upgrade activity requiring attention, you will see a corresponding banner notification during your ServiceNow experience. The banner messages, detailed descriptions, and appropriate actions are highlighted below: Banner Message: SIC completed, but VPN still active If you receive this message, OneStream has identified that you have successfully transitioned from VPN to SIC, but your VPN connection remains active. It is important to retire your VPN connection ASAP. Action: Submit a case to confirm OneStream can retire your VPN connection. The banner message will be removed once your VPN is removed. Banner Message: In Migration Readiness If you receive this message, OneStream has identified that you have not completed your v8+ readiness within the allotted three-month period. Readiness activities include Marketplace solution upgrades, .NET 8 Desktop Runtime distribution, SIC Local Gateway Server availability, and OIS subscription creation. Completion of readiness activities are a pre-requisite to the v8+ upgrade process. Action: Navigate to your Cloud Migration Readiness Case and complete the Action Items to move your migration forward. The banner message will be removed once all Action items are submitted. Banner Message: Submit Software Upgrade If you receive this message, OneStream has identified that you are operating VPN past OneStream’s issued End of Service date. If you were previously granted a VPN service extension, that has now expired. You must plan to transition from VPN to SIC ASAP. Action: Submit a Software Upgrade for v8+ in the Service Catalog to begin the process of transitioning from VPN to SIC. Banner Message: OneStream v8.0.x or v8.1.x - .NET 6 If you receive this message, OneStream has identified that you are operating on Platform v8.0.x or v8.1.x, which were developed using Microsoft’s .NET6 development framework. Microsoft has stated that support for .NET 6 ended as of November 12, 2024. Operation of OneStream v8.0.x or 8.1.x increases your risk to .NET security vulnerabilities that will not be corrected with .NET 6 patches. Action: Submit a Software Upgrade in the Service Catalog to upgrade to Platform v8.2.2 or higher, which were developed with the .NET 8 development framework (supported through November 2026).38Views0likes0Comments