Pavel Kabir

@Louis Sterio2 we're also interested in getting account balances API access for testing purposes if possible, especially performance testing is crucial for us 🙏

Thank you very much @Louis Sterio2!

Hi @Louis Sterio2! While experimenting with the REST API the other day, I noticed there was a definition for a journal entry line, which I believe 1-1 maps to GLENTRY in the XML API; however, I couldn't immediately find an object that would correspond to GLDETAIL. With Velixo, our clients expect to be able to configure transaction-level drill-downs in both the summary (GLENTRY) and detail (GLDETAIL) format, just like the General Ledger report in Sage Intacct itself. If I missed, could you please point me to the definition of GLDETAIL, and if it is indeed not exposed at all, would that be a possibility? Thank you 🙏

Thanks @Louis Sterio2 , please keep us posted if there is any development 🙏

Hi @Louis Sterio2! This feature would be awesome to have. Do you think it could be implemented on your side?

We have verified that this works correctly. Thank you!

Very cool Louis! Glad to be useful 🙂

Steps to replicate: click the "Accept" button in the consent form two-three times in rapid succession. Actual result: Expected result: no issues. Looks like the "Accept" button has no idempotency, might be an easy fix!

That's a pity... We nevertheless provide our users with such a capability, however this happens at the expense of an extra API call to obtain the object definition. For now it feels like it's a common debugging and "drafting" scenario (retrieve everything, see what's inside, then narrow down the data to the columns that you need), but with the workaround above it may actually have worse performance than if "*" was allowed in the first place...

Thanks so much Louis! We will verify this on our side and provide feedback.

Every time we tried using the asynchronous version of "Get Account Balances by Dimensions", we discovered that frequently was taking 2x-8x more time than the synchronous version. For example, if a relatively large request took 30 seconds with the sync version, async version could get stuck for 2-4 minutes. Due to that reason, at Velixo, we default to synchronous balances. The problem with this is that we don't know in advance whether a client is too large for sync balances or not. Therefore, it's not infrequent that: We start the client implementation Client builds out their reports and reaches out, frustrated, to our support, complaining about timeouts We process the support escalation and recommend enabling the "async balances" setting The setting switches Velixo to use the asynchronous version of the SDK function What we'd love to do is to enable async balances by default to skip the "dramatic" flow above, improve UX and decrease the support workload... However, for us to do so, the async balances API needs to produce the results as fast as the synchronous one, while at the same time never timing out. After a talk with @Louis Sterio2, I confirmed that async calls go into the report processing queue and can sometimes get stuck there for a while depending on the site load. So, to sum up, at the moment, the UX with async balances is very unpredictable and the clients need to sporadically wait a very long time for their report to complete... Unfortunately this doesn't feel or demo well! What I'd like to propose, and I know it will probably require cross-team cooperation, is to make the report queue a priority queue, where "reports" requested by API calls will always take priority. This will bring the performance of balances by dimensions very close to the sync version!

Velixo is a reporting add-in, which means that most of the time, the user can log in to the company level (without specifying an entity) – they'll still be able to retrieve all data they have access to through the API. Therefore, in our connection set-up window, for simplicity, we don't even expose an "entity" field. The only exception when we're being "smart" is the push-back scenarios when we update records in Sage Intacct: whenever one of the dimensions used is entity-scoped, we: Temporarily change the user's session to an entity-scoped session. We can do that because we have the session ID / user credentials. Write back the record Change session back to the company level I spoke to both @Louis Sterio2 and Karsten about this but obtained mixed understanding whether a trick like this is possible with the REST API with an Intacct OAuth flow (very important, not username/password). So my question is this: is it possible, with the REST API, to seamlessly exchange company-scoped bearer token to an entity-scoped bearer token, and vice versa? If not, I guess it's not a question but a feature request, because the absence of such functionality will break our flow once we upgrade to the REST API...

The legacy readByQuery in the XML API supported specifying "*" in the field list, which was perfect for: Local troubleshooting in Postman, without having to look up the object model first to see what fields are available and tedious copy-pasting User-initiated query's where the user "wants everything" in a tabular form without having to specify an explicit "SELECT". Unfortunately, query in XML / REST based API does not support this. Right now, to enable this scenario, we need to warm up local object definition caches and inspect the model the user wants, so as to retrieve the available field list. It would be so great (save an extra API call and improve report responsiveness), if we could pass a "*" to the query just as we could to legacy readByQuery in the XML API. We discussed this idea briefly with Louis at Transform and he thought it was an great suggestion, so I am filing it here.

We're in reporting space, and frequently people will need to ad-hoc retrieve figures for a certain set of e.g. locations, projects or departments, for which dimension group might not exist in Sage Intacct (since it's ad-hoc reporting). Doing it one-by-one is slow and inefficient, so for some dimensions we're creating (and deleting) a dimension group on the fly to participate in the filter condition of the request. Pseudocode: User wants to report for three different projects P1, P2, P3 (separate columns per project) We create dimension group ADHOC We issue an account balances by dimension request with "GROUP BY" Project and WHERE ProjectId = ADHOC We retrieve the grouped dataset and show it in the report for P1, P2, P3 We delete dimension group ADHOC To clarify, the where condition is needed to avoid loading too much, and at the same time we're trying to avoid N different requests, N can be quite large on some reports. Problems with this approach: Employee-type users cannot create dimension groups on the fly. Those are extra requests that make the experience slower. Proposed approach: Allow specifying multiple values for locationid, projectid, vendorid ... and other dimension filters. In the REST API, you could accept an array for each of those parameters that should be translated into an "IN" filter in the SQL. This would give us such a performance boost!