I am trying to insert an invoice, credit memo, and invoice using IPP.Net. How do I know what the AccountID, ClassID, or EntityID is? When I used the Web Connector to write a previous interface, I was able to specify these things by FullName. Do I need to do some type of query to get all of the IDs for future use? If I do that, will the IDs ever change through any processes, such as re-indexing, or is the ID permanent?
If you're integrating with QuickBooks Online:
Yes, the IPP APIs for QuickBooks Online only accept Id values. You will have to query for the objects so that you can get their Id values to use them in future invoice/credit memo add requests.
If you're integrating with QuickBooks for Windows:
The IPP APIs for QuickBooks desktop for Windows can accept either Name values, or Id values. So you could either query to get the Id values, or just use the Names like you do in the SDK.
A few things worth noting:
The next version of data services Intuit is releasing (v3) will likely be released summer/fall 2013. v3 data services will only accept Id values like QuickBooks Online does in v2. So, if you want to plan ahead for the future, start querying. :-)
Regarding this:
If I do that, will the IDs ever change through any processes, such as re-indexing, or is the ID permanent?
The Id values are permanent - they should never change. The one exception to this is if something gets really fubar'd on Intuit's end and they reset someone's Sync Manager to force QuickBooks to sync to a new online realm. But this generally shouldn't happen in production.
I tried a few things, and I seem to have found the answer. The Id property does not bind on its own through Autogenerate of the gridview. That seems to be because it is a class and not a simple property. You have to specifically bind Id.value.
Related
I'm trying to make an app that sells a service, for which users pay based on the amount of time they've used it for, so I don't have a physical shipping address involved.
I want to be able to allow my users to save and then reference saved cards in future transactions. I know the way Stripe tracks a specific customer is through a customer_id, but I'm not sure how to attach a card to a specific customer_id and then reference it in future.
Also, I'm a little confused on the use of ephemeral_keys. Some Stripe tutorials talk about needing these on the server side, and some don't mention them at all, and that leaves me very confused.
This one talks about ephemeral_keys while creating a paymentIntent: https://stripe.com/docs/mobile/ios/basic#
And this one doesn't: https://stripe.com/docs/payments/integration-builder
Any help would be greatly appreciated! Please let me know if you need any more information from me.
PS: If you could also point me to some of the relevant View Controllers Stripe uses to save new cards and display saved cards, I'd be more than grateful!
The flow on https://stripe.com/docs/mobile/ios/basic includes the Customer for your payment context, which will cause the created PaymentMethod to be attached to that Customer. You can verify this after the initial payment by retrieving the PaymentMethod on your backend with your secret key and checking its customer field [0].
If you have a PaymentMethod and want to attach it to a Customer, you'd use the API on the backend [1].
You can retrieve a list of the Customer's existing PaymentMethods via the API [2] on the backed as well (again, with your secret key). Then you can pass a list of their id's and some identifying feature (last 4 digits, as an example) to your app in order to display and let the customer select the one they want to use. Then you take that PaymentMethod's 'id' and use it to create the new payment.
Ephemeral keys are usually only used with the iOS (or Android) SDK's, so when you're using the backend of your integration (i.e. the part that is running on a server somewhere and not distributed with your app) you generally don't need to worry about them.
[0] https://stripe.com/docs/api/payment_methods/retrieve
[1] https://stripe.com/docs/api/payment_methods/attach
[2] https://stripe.com/docs/api/payment_methods/list
I've been trying to find a way to store a piece of data relative to a customer in my store. Ideally I was hoping to be able to create a Metafield that would store a single numerical value and be retrievable by the customer's id or email.
Any thoughts or suggestions would be really appreciated. Ideally I'd like to be able to handle everything in the liquid layer by editing the html and css of the store directly. A custom app with API integration is another option but less desirable as it doesn't seem necessary and would appear to be a lot more work.
EDIT: Tried piggybacking the order (thinking orders are unique to users) but it doesn't appear that the order object is created until the checkout is complete so that isn't really useful since I want to be able to attribute the user to a session click that led them to the store.
Thanks,
Alex
You will want to use an App. First, off, that is the only way for you to alter any objects in Shopify. Secondly, you can easily store simple things like counter values on the Customer resource using metafields. Third, anything you do with metafields on the Customer would be easily visible to the customer, since you can expose those metafields using Liquid. Fourth, if you choose to use JS you must use the App Proxy pattern. Shopify will then send your JS XHR payload to your App endpoint in a secure fashion.
So your needs and how to do are not new, they are old skool in Shopify terms and very straightforward to implement.
The "country" field in the PayPal transaction history CSV exports is almost always empty. However, PayPal must know the country where a transaction originates, and in fact tools such as Putler can display the country for nearly all transactions.
I wish to obtain this data myself, but since the export doesn't appear to have it, should I obtain it by using the API? And which of the APIs wold be appropriate to use for this purpose?
Thanks in advance.
Yes you can probably do this using the API. First you'll need to search your account's transaction history. After that you'll get a list of transaction ID's, you can then retrieve information about a specific ID which includes the country code of the buyer.
You can see more details here: https://developer.paypal.com/docs/classic/express-checkout/ht_searchRetrieveTransactionData-curl-etc/
We are trying to query Customer Master for "TEST CUSTOMER", But Quickbooks is returning an error saying "The name "[TEST CUSTOMER]" of the list element is already in use."
We tried searching customer master for the above customer, but could not find it in QB. We searched the entire list of customer which includes inactive as well but no luck.
We are using RSSBUS ADO.Net Provider for integration. When we communicated to them, they said, there might me issue with the Company File.
Can you please help us resolve the issue, or tell us the cause of the issue?
-Santosh
QuickBooks has a UNIQUE constraint across the combination of (vendors, customers, employees, "other names").
So, it could be that a vendor or employee already exists with that name.
You might also check to see if the customer is marked inactive (inactive customers don't show up in default queries).
A client just reported that his website to Salesforce integration is not working properly. It appeared that Account ID which is needed for executing REST queries has changed, so that I was using a non-existent Account ID.
I've had a look in the Account history log in SF, but nothing there said anything about any updates to it's ID. I am 99% sure I was using the correct Account ID before, as I always test all features before handing out the project. Any ideas how could this happen?
Thanks.
Account IDs do not change, ever*.
* unless they are deleted, either to be brought back later (Acct Id will be different) or merged into another account. It is also plausible (I have no idea about this one, I'm just spitballing) that they could change if your data are migrated to another instance (e.g. na10 -> na11)
That said, hardcoding IDs should be avoided if at all possible -- it's virtually always possible, and if it isn't it should be documented extensively and unambiguously -- because they will be different in the sandbox, where you are presumably doing your testing. You do test in the sandbox, right?