I was messing around with the Square Connect API, and after uploading some items and finding out they had incorrect pricing (I was sending the amount in dollars, not cents) I decided to delete all of the items and start over. I am passing in item ids so that I can cross reference the items with our in-house database. Unfortunately, it appears that after I've deleted an item, I can't recreate it with the same old id. How can I fix this?
Unfortunately, item and variation IDs can never be reused for a given merchant. I will update the documentation to better clarify this limitation.
As a couple of potential solutions for your issue:
You could recreate your item library with item IDs that all have the same prefix, followed by the corresponding ID in your in-house database. Then prepend or remove the prefix when translating between IDs in your two systems. Of course, this solution is still susceptible to the same root issue, so you'd have to make sure not to delete any items.
Store the ID mapping in the user_data field of your item variations. You can set the user_data field with the Update Variation endpoint.
Related
I Have a Google Sheets set up for a community I run.
I have two columns, each linked to a form. One for recruited members and one for kicked members and members who leave
What I want to do is Have one more column in my sheet that shows only the people currently in my community and the problem arises when a former member who is on the kick list rejoins the community.
I believe the easiest method may be to remove the name from the kick list when a new member is added.
Alternatively, it may be possible to remove a name from the kick list if there is a more recent entry for that name on the recruited list
Here is a copy of my set up: https://docs.google.com/spreadsheets/d/1CqUSz_C--jidkxGF-WpNxM3cgWMndgqJnC2fEX-H0JI/edit?usp=sharing
I believe the easiest method may be to remove the name from the kick list when a new member is added.
this would be indeed the best method. to make things easier you could create one more column to check joined members from a certain date onwards if they are present in kick list so you could then just track down specifically those names and remove them within the kick list
I have been writing an Square Connect integration that rests on the fact that an item has one and only one ID, even when it is present in multiple locations. After testing with a subset of products on a separate Square account/App, things were working smoothly. I have now pointed the integration at the "real" Square account/App, using that account's credentials, which contains the same subset of products in addition to many others, and the integration is failing. It seems I have many items that now have a unique ID for each location. This means that a single item has multiple IDs. The item only displays once in the Square dashboard, but there are two unique IDs associated with it. In fact, I have one item that has two IDs, yet those IDs share a single variation ID.
I have also noticed two different formats of IDs, which from my research sounds like a variation due to information created pre- and post- a certain date.
Format 1: XXxXxXXX-xxXX-XxXx-XXX-XXXxxxxxxxXX
Format 2: XXXXXXXXXXXXXXXXXXXXXXXX
I suppose the first question is, is this normal behavior? And if not, any thoughts on what might be causing it and is there a way out of it?
There are some nuances to items with older accounts. Items were originally scoped to a location, which doesn't quite make sense with larger multi-location businesses. Internally we are migrating to a location independent item catalog, which should be invisible to you as an end user (save for the change in formats, like you mentioned) and depending on the date of your account it might have a mix of "old" and "new" item ids. It seems like you have basically a "new" location and an older one.
Basically in our current model you are only guaranteed that items will have unique ids within a location. We are working on new APIs that will allow you to manipulate items across locations more easily.
I'm doing a bulk move of contacts to a different folder.
I know I can move each contact one by one to get the new ItemId after moving. But that'd be expensive in terms of number of EWS calls.
This property provides a trace for related objects, such as message copies, and facilitates finding unwanted occurrences, such as duplicate recipients.
Above lines are from this MSDN link. But I don't know if I can assume the following from that:
Can I assume no two contacts will have PidTagSearchKey the same if it is just moved from one folder to another?
If not, is there any other way I can bulk move contacts and still get the new ItemIds using less number of EWS calls than moving contacts one by one?
Thanks in advance for any help!
Just figured out that I cannot use PidTagSeachKey because if someone has copied a contact and edited the 2nd one to make it a different contact, both will have the same PidTagSeachKey.
I'm utterly baffled by this and I think I must be doing something wrong. Is it possible that MS actually neglected to add sorting ability to queue items? Here's my queue item view of Service Activities:
I must be missing something? How can people use queue items without sorting?
You need to add the Entered Queue column to your view (it's part of the Queue Item entity).
System views can only sort on columns on the view being shown, not on related columns. In your example above every column is part of the "Regarding" relationship, which may be a related Contact/Case/Activity/Opportunity/whatever. There's no guarantee that the regarding record even exists for each queue item, so it's not possible to sort by it.
"Entered Queue" is in the default view - just add it back and sort by that, and you'll get items added to the queue the longest time period ago float to the top of the list as you'd expect.
I have a web application that syncs Outlook contacts to a database (and back) via CDO. The DB contains every contact only once (at least theoretically, of course doublets happen), providing a single point of change for a contact, regardless of how many users have that particular contact in Outlook (like Interaction or similar products).
The sync process is not automatic, but user-initialized. An arbitrary timespan can pass before users decide to sync their contacts. A subset of these contacts may have been updated by other users in the meantime.
Generally, this runs fine, but I have never been able to solve this fundamental problem:
How do I doubtlessly identify a contact object in a mailbox?
I can't rely on PR_ENTRYID, this
property changes on contact move or
mailbox move.
I can't rely on my own IDs (e.g. DB
table ID), because these get copied
with the contact.
I absolutely can't rely on fields
like name or e-mail address, they
are subject to changes and updates.
Currently I use a combination of 1 (preferred) and 2 (fall-back). But inevitably, sometimes users run into the problem of synching to the wrong contact because there is none with a given PR_ENTRYID, but two with the same DB ID, of which the wrong one is chosen.
There are a bunch of Outlook-synching products out there, so I guess the problem must be solvable.
I had a similar problem to overcome with an internal outlook plugin that does contact syncing. I ended up sticking a database id in the Outlook object and referring to that when doing syncs.
The difference here is that our system has a bunch of duplicates that get resolved later by the users. When they get merged I'll remove the old records and update outlook with all of the new information along with a new id.
You could do fuzzy matching to identify duplicates, but duplicate resolution is a funny problem that's mostly trial and error. We've been successful at implementing "fuzzy" matching logic using the levenshtein distance algorithm for names and addresses cleaned down to a hash code.
Good luck, my syncing experiences have been somewhat painful.