Jump to content

About This Club

Join our Sage Intacct Developer Club, where our mission is to help developers succeed by providing quick, reliable community driven support, providing a friendly community, and encouraging the sharing of knowledge. Whether you're a seasoned developer or just starting out, join us to share solutions, experience a supportive community spirit, and make things a little bit easier together!
  1. What's new in this club
  2. 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!
  3. 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...
  4. 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.
  5. 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!
  6. Hello, I see documentation for using custom fields and for how to query custom objects. Would it be possible to also include documentation for how to use Get/Post/Patch/Delete for custom objects? Thanks!! ______________________ (For reference: Custom Fields: https://developer.sage.com/intacct/docs/developer-portal/guides/custom-fields/ Query Custom Objects: https://developer.sage.com/intacct/docs/openapi/common/core-model/tag/Models/#tag/Models/operation/post-services-core-query-core-model )
  7. @Sterio, Louis Thank you! I wish I was going to Transform, but unfortunately I can't make it this year. It would have been great to catch up with you.
  8. Submitter: Tierney Santoro, The Menta Education Group Business Need: : As a multi-location, single entity, we needed a way to record a customer’s purchase order number for each of our own locations based on the dimensions ‘Location’ and ‘Class’. The solution we arrived at was to create an intermediary lookup table that housed custom relationships between the customer, location, and class dimensions. The lookup table was then used to populate the PO number on order entry transactions using an API trigger call. While we are using the lookup tables for this specific use case, this same logic could be implemented for any number of use cases that require multi-criteria lookups. Pre-Requisite: Ensure that Platform Services are enabled for your account. Tool Limitations: - FAQ's: - Objects and Fields: Object: Order Numbers (Lookup Table) Relationships: Many-to-One Customer Many-to-One Class Many-to-One Location One-to-Many Order Entry Transaction Fields: Purchase Order Number (Returned Value, Text) Concatenated ID (Record Name): Notes: We use a concatenation of “Location ID” + “Class Name” + “Customer ID.” For example: “LOCATION1-TUITION-CUSTOMER1.” This allows us to utilize information from the order entry transaction to find the appropriate record. This could be pre-populated using an ‘Update Field’trigger after the record is created. • Related Relationship Fields which are auto-created Usage Steps: 1. If you do not have an application you will be adding this to, create a custom application. 2. Create the lookup object with associated relationships and fields as described above. 3. Add the object to the associate application menu so that users can enter new lookup values. 4. Update permissions to access the lookup object. 5. Open the object definition for the Order Entry Transaction. 6. Create two triggers: one to attach the related lookup record, and the second to update the returned value field. They should be listed in this order so the execute in correct sequence. Attach the related lookup record: Trigger Type: Attach related record Trigger: After Create Relationship: Lookup Table Relationship Formula: this returns the same value that was used for the ‘Record Name’ for the lookup table. (See explanation above.) return "{!SODOCUMENT.INV_LOCATION!}- {!SODOCUMENT.TUITION_TYPE!}-{!SODOCUMENT.CUSTVENDID!}" Return lookup value: Trigger Type: Intacct API Trigger: After Create Document Template: (Create new, see step 6 below.) Trigger condition formula: {!R_Menta_PO_SES_Tuition.id!} > 0; (This is the name of our relationship field on our Order Entry Transaction. Note, if no relationship exists Intacct returns 0.) Create a platform document template with the following API call: Template Type: Generic Code: {!R_Menta_PO_SES_Tuition.menta_po_number!} <update_sotransaction key="{!SODOCUMENT.DOCID!}"> <customerponumber>{!R_Menta_PO_SES_Tuition.menta_po_number!} </customerponumber> </update_sotransaction> (Updates the current order entry transactions purchase order field with the related lookup’s purchase order number.) Lookup Application.pdf Lookup Application.docx
  9. Hi @Sterio, Louis, I attached an example that would have worked before. You can copy 'bt-smartfx2-test'. Thank you! update_APPYMT_Request.xml
  10. @AJ Gregg, That is concerning. Can you provide me the API call that worked prior to the release which is failing now? We should have a way internally to test this in the branch prior to R1. Also let me know the company ID we will need to copy it down to a dev box to test this in the prior branch.
  11. I also created support case # 00640859 yesterday. The first reply was a little off base. They didn't really read my case notes. My concern is, we had to make a quick change to our code so our MPP Apps would work again. If Intacct removes this change without notice, it will break our app again.
  12. FYI -- It looks like the 2024 Release 1 has a change to the Update AP Payment <APPYMT> API where <AMOUNTTOPAY> is required now when paying from a bank with a different currency than that of the transaction. The <AMOUNTTOPAY> always existed on Create and was required when paying from a bank with a different currency than that of the transaction, but <AMOUNTTOPAY> wasn't required and is not in the list of fields on the Update AP Payment API. The documentation for Update AP Payment does not reflect this change, yet.
  13. Not sure what you hit with the smart rules, but I moved the ref id line and it went through without error. Wouldn't have thought to try that! Great catch and thank you very much!
  14. The order of the fields matters here. refid is in the wrong position. This works however it looks like you have a smart rule preventing the update at this point. <function controlid="0be78e3c-47d1-4fed-ac0c-ee9a201ababc"> <update_otherreceipt key="4090"> <receiveddate> <year>2024</year> <month>01</month> <day>06</day> </receiveddate> <refid>Mateo Receipt - 256749</refid> <receiptitems> <updatelineitem line_num="1"> <amount>10.00</amount> </updatelineitem> </receiptitems> </update_otherreceipt> </function>
  15. We're thrilled to share the recap and video recording from our second Sage Intacct Developer Meetup, held on November 8th, 2023. It was a fantastic event filled with insightful discussions and deep dives into the latest developments in Sage Intacct. Video Recording: For those who couldn't attend or want to revisit the valuable content, we've uploaded the complete recording of the meetup. You can access the video here. Feel free to share this link with your colleagues or anyone who might be interested in Sage Intacct development. We encourage you to continue the conversation on our forum and share your thoughts, insights, and questions related to the meetup.
  16. We're thrilled to share the recap and video recording from our first-ever Sage Intacct Developer Meetup, held on August 10th, 2023. It was a fantastic event filled with insightful discussions and deep dives into the latest developments in Sage Intacct. Video Recording: For those who couldn't attend or want to revisit the valuable content, we've uploaded the complete recording of the meetup. You can access the video here. Feel free to share this link with your colleagues or anyone who might be interested in Sage Intacct development. We encourage you to continue the conversation on our forum and share your thoughts, insights, and questions related to the meetup.
  17. Louis, I made the recommended change to the formatting of the receiveddate element. In addition, I was able to enable logging and capture the XML messages. Surprisingly, the updated format looks correct, but I am still getting the exact same error message. <function controlid="0be78e3c-47d1-4fed-ac0c-ee9a201ababc"> <update_otherreceipt key="4090"> <refid>Mateo Receipt - 256749</refid> <receiveddate> <year>2024</year> <month>01</month> <day>06</day> </receiveddate> <receiptitems> <updatelineitem line_num="1"><amount>10.00</amount></updatelineitem> </receiptitems> </update_otherreceipt> </function> Response control status failure - XL03000003 XML Parse schema error: Error 1871: Element 'receiveddate': This element is not expected. Expected is one of ( description, supdocid, currency, exchratedate, exchratetype, exchrate, customfields, inclusivetax, receiptitems ).. Line: 1, column: 0. [Support ID: 4plML%7EZbfbRWEcBW86HZp32_DNJwAAAAo]
  18. Thanks Louis! This is resolved! It turns out URL's should NOT have a carriage return at the end! #Resolved!
  19. I do have those values. I really appreciate this. I'm at the beginning of a project for a client and I'd REALLY like to start my development. [email protected]
  20. Alright I got it to work on my side I was having the same issue. Do you have these environment variables setup and populated in both initial and current value columns? If you do I will setup a call with you so we can review.
  21.  
×
×
  • Create New...