Want to know the Acumatica REST API to be used to get Account Inquiry / Customer Open Balances. If no such web services then how to extend end point using which modules of acumatica erp
Not sure exactly what information yo are looking for but maybe the following screens could contain it :
Account Summary (GL401000)
Account Detail (GL404000)
Customer Summary (AR401000)
Customer Detail (AR402000)
Though only one of these screen is already mapped in the Default endpoint of version 18.200.001 (Account Summary -> AccountSummaryInquiry)
If you need information from the other screen, you will need to either create a custom endpoint or extend the default one (I recommend extending).
Here is information on how to do both:
Creating a new endpoint, it also contain information on how to add new entities in an endpoint : https://help-2019r1.acumatica.com/(W(14))/Wiki/ShowWiki.aspx?pageid=709351cc-566a-47b3-b153-3a9fdd690ce0
Extending an endpoint : https://help-2019r1.acumatica.com/(W(13))/Wiki/ShowWiki.aspx?pageid=c450492e-06fe-4563-95c3-efa76975415b
I recommend that you take a look at the way the AccountSummaryInquiry entity is defined and follow the same way to create the other screens if this is what you do. I mean by that that you put the parameter of the inquiry in the top level entity and the fields of the grid in a detail type sub entity.
And in order to retrieve the information properly I recommend that you use a PUT request instead of a GET as this is the proper way to do so as mentioned in the following article:
https://help-2019r1.acumatica.com/(W(12))/Help?ScreenId=ShowWiki&pageid=6340cff3-4732-4231-9e42-5d1e5e65b5dd
Related
I have 2 queries based on the following :
I recently followed this DocuSign article to pass a supplied document to Docusign via the API:
https://www.docusign.com.au/blog/get-the-flow-sending-docusign-envelopes-microsoft-power-automate?_ga=2.99447774.1174083755.1646148960-1179341585.1645460870
Query 1 - This all works apart from the AutoPlace text just isn't getting picked up. I added the variables as described in the article and referenced them in the document footer. The document is passed through the API call and the invitation to sign goes out ok. Is there anything I'm missing here? I can open the document for signing but docusign doesn't go to the places where the AutoPlace tags are, just leaves it open for the user to decide what to do. I've previously tried using AutoPlace using templates, but this is a document that will be sent through the API as it is provided by our users (with the correct AutoPlace intact). The article hints this should just work.
Update : this is now working but need advice on text color
signing screenshot
Update : Showing white signature on black background
white signature
Query 2 - Once the user has signed the document using the above, I want to trigger a power automate flow off. There is a trigger for this but when I try to form the connection to DocuSign, there is only a login for the main account, not the developer account. So the account where I've made the account from isn't the one where I can fire off the triggers from. This makes it impossible to then fire a flow when it has been sent to the API and subsequently signed. Is there a way to use the trigger using the same account as the API account? If not it seems a bit crazy that I can start the process using the API but then can't fire flows from the result of the signings.
We have a company account ( I'm working on behalf of Transport for Wales) but was told there is no API support at all, which also sounds a bit bizarre. Hoping someone can help me!
Query 1 - there's an AutoPlace settings that determine the scope - document/envelope for AutoPlace. You may want to see if the issue happens also when you use the web app and not from API - if the same challenge - then you need to contact support to change this scope. If not, it may mean you're not setting your templateRole correctly. It must match the same one that was defined on the template (case sensitive).
Query 2 - no, the OTB connector is production only. For the developer account you will need to use a custom connector for any REST API, not the one provided for you.
I am using Azure API Management to proxy requests from Internet to our backend systems. I have a Product entry on Azure Portal and an API entry associated with the product. Generally access to the API must be by subscription, but I would like the method returning OpenAPI specification (as well as probably few other methods) to be accessible without subscription (freely).
I see "Requires subscription" checkbox on the Product level as well as on API level, but not on a method's level. So I need either:
bypass subscription check for certain methods while keeping access by subscription for others, or:
same but vice versa: keep the access free for API, but enforce subscription check for certain methods (not preferable, as this fraction is greater).
I checked the list of policies and did not find anything applicable for my case. Moreover this link states:
Subscriptions can be associated with various scopes: product, all
APIs, or an individual API.
Is there a way I can workaround this limitation?
I mean that, maybe you wanna some of the methods(less amount) in an Api can be called without a subscription while the left need. And I searched the ms document but failed to find such policy.
The link you provided also intended that. From my point of view,
how about trying to add a separated Api containing those methods that
don't need subscription?
I've been tasked with setting up our company's Azure B2C environment. I've made a lot of progress and have had to use Custom Policies, as the default User Flows don't give us enough flexibility.
One of the requested features is to have a section in the SignUpOrSignIn policy, so that when a user signs up for the first time, we want to validate their postal address through an address validation api provided by a third party.
The way the api works, is first you pass in the post code, eg: AA11 1AA. The response will include a list of all the available addresses for the provided post code. You then call the api a second time with the unique id of the selected address, and this time the response breaks the address details out into each of its parts, eg: Line 1, Line 2, Town, County, Post Code.
So far I have an input for the postcode in the UI. I need to take this value and pass it to the api.
I now want to be able to display the list of addresses to the user in a DropdownSingleSelect list. Is it possible to dynamically populate these, rather than hard coding into the xml file? I also need to hide this list until it is populated.
Then after displaying the list to the user, they will select their address. This will then need to submit a second call to the api with the unique id.
Then the response needs to be populated into each of the address fields which are hidden up to this point. I also need to prevent the button at the bottom of the page to create the user from being active until this sequence is complete.
Are these actions possible? Or are the requirements too complex for B2C? Any suggestions?
You can generate a dynamic dropdown box with javascript and some hidden fields rendered by B2C after getting the details from the REST API.
See this sample:
https://github.com/azure-ad-b2c/samples/tree/master/policies/selectemail
I have some doubts regarding the custom connector we are trying to build for docusign : -
Regarding the license plan that need to be bought by the customers who will be granting access for our connector to collect data from their docusign organization account. I am looking at the link https://www.docusign.com/products-and-pricing. API access support is mentioned in only the advanced solution. So I was wondering whether only we need to have "Advanced solutions plan with APIs support" plan or all our customers need to API access support in order to fetch their data.
As per the documentation, to make the REST API calls we need two fields 'base_uri' and 'account_id' (https://developers.docusign.com/esign-rest-api/guides/authentication/user-info-endpoints). Now, the response of userInfo API call gives an array of accounts and its respective fields. My doubt is, if multiple authenticated users (more than one accounts) are returned in this array but all are part of same organization, will they all have different account_ids. Main concern here is, will there be several Base Paths (https://developers.docusign.com/esign-rest-api/guides/authentication/user-info-endpoints#form-your-base-path) to make API calls?
2a. Further question is, what is the significance of 'is_default' field?
Is this related to main account (if is_default is true) using which we will create our Base Path?
Since this is a tech/engineering forum I'm going to answer only question #2 as question #1 is more of a business/sales question.
The reason you may get multiple accounts is that an authenticated user in DocuSign can be a member of multiple accounts. That said, it's the same user. Meaning, say foobar#blah.com has an account 123 with company X and account 456 with his school, then it's possible that when foobar#blah.com authenticates (With the same password!) to DocuSign we have a list of accounts associated with that user. We give you all of them when you make the API call. The default one is the main one that you would see when you log into our web app. You can decide yourself as the user which one is the default. Users who log into our web-app then see an option at the top-right to change accounts.
and yes, every API call is associated with a specific account. So when you construct the urls for your API - you do need to know which account for this user you are making the API call for. Your application can decide how to handle this.
Hope this helps.
If a person has previously filled out a contact us form on our website, the next time they visit that form I would like their information pre-populated. Using Kentico EMS and the form builder, how can I make that happen?
you can access the contact informant via macros or custom macro methods and place it in the contact form default values (I would use an alternative form), but often you do not know if the user already exists unless they are logged in or enter the same email (which you would then need to add a client side trigger to Ajax an api once the email field is filled out, check for that contact in the api, return json of their info and populate the form).
to build the api you can either use the Kentico rest service or if you need more flexibility use the web part to api coupled with a repeater with custom query, adding the right where condition through macros.