Hopefully quick question here - we need to be able to determine if a Purchase Order (either at the header or line level) has been changed after it was created, in order to be able to integrate those changes to our accounting system.
What object/fields should I use to determine this? I do not see anything on the Order object, and also explored to try to find the info from the LogEntry table, but cannot find any object that houses that in the API (another thread mentioned a LogEntryList object, but I have been unable to locate it).
Any help you can provide would be greatly appreciated, thank you!
Additionally, where is the VersionStamp field for Products? I am unable to locate it on the Product object (although I see in SQL there is a RowVersion field that is a timestamp field, similar to VersionStamp for Jobs).
Additionally, whenever we run GetProductCollection or GetStockedProductList, etc., we are getting no results, but I am certain there are numerous products in our database. Has anyone run into this issue before or is there an obvious mistake I am making? (code snippets below: each of these returns no records)
ProductCollection all_products = ProductCollection.GetProductCollection(ProductType.ProductOrConsumable);
ProductHistory productHistory = ProductHistory.GetProductHistory(Guid.Empty);
ProductConsumableList all_consumables = ProductConsumableList.GetProductConsumableList(Guid.Empty);
ProductComponentList all_components = ProductComponentList.GetProductComponentList(Guid.Empty);
StockedProductList all_stocked_products = StockedProductList.GetStockedProductList(Guid.Empty, ProductType.ProductOrConsumable);
Update on this piece: it appears there is a bug in the enums available for retrieving product lists. ProductType.Product and ProductType.Consumable work, but ProductType.All and ProductType.ProductOrConsumable do not.
If I need to then retrieve a list of ALL products and consumables, is best practice to run two GetStockedProductList calls and merge the two lists together?
Only the few commonly used ProductTypes are accepted by the select criteria (Product, Consumable & Recurring) in ProductCollection currently, from among the master list of ProductTypes.
Similarly, VersionStamp exposes SQL Server’s mechanism for version-stamping at a table level, the property may not be currently available in Objects not commonly tracked for changes. Also to note, since it is a database mechanism it is specific to a Table.
I’m including these in the previous ticket created, on a related post, to expose VersionStamp in collections, so these will be available in the upcoming release.
Thanks for posting.
Thank you for the response, this helps me understand the capabilities of the API.
Just a few follow-up questions:
- To clarify, does your statement “the [VersionStamp] property may not be currently available in Objects not commonly tracked for changes” apply to both Purchase Orders and Products? I.e. neither of those currently has versioning available via the API?
- Will the VersionStamp property be available for both of these entities in the upcoming release?
- Do you have an estimate for when this release will be available to us?
Thanks again for your help with this.
Just checking in on this - question (3) is what we are most interested in here, as that timeline will determine whether we need to implement workarounds in the meantime. Knowing this estimated release date would help with our planning immensely.
Thanks so much,
The three updates are already in dev. I’m in talks with the rest of the team to check the possibility of a quicker point release for you so it doesn’t have to pass through all the formalities of a general release. I’ll get back to you on the timeline in 1 day after I conclude the discussion with the team.
Thank you for posting.
Thanks so much for the quick response and for following up on this. That sounds good to me. An earlier release for us (even if just in our Dev environment, to allow us to proceed with dev and testing) would be extremely helpful if we were able to make that work.
Let me know if there is anything you need from me in the me in the meantime.
Apologies - one more request to include in this potential earlier release. I noticed that Serialized Parts also have a VersionStamp field in the SQL database, but I couldn’t locate it in the API on the SerializedPart object - could this field also be added in to the API?
And one question - if a Product’s (i.e. PartNumber’s) version stamp changes, does it also update the associated SerialNumber’s VersionStamp? And vice-versa, if a SerialNumber’s VersionStamp changes, does the base product’s VersionStamp change? Or are these not tied together in this sense?
Let me know if you have questions or concerns on this one.
I’ve included the VersionStamp on Serialized Parts to the list of updates to be made. Also, we’re considering possibility of a high performance lookup Dictionary of ID and VersionStamp, fetch-able per Table.
Since VersionStamp is not a coded feature but exposes the built-in SQL Server TIMESTAMP, the SerialNumber’s and Product’s VersionStamp’s are independent of each other, except in cases where the update in one brought about a change in the other.
We’re looking at getting this point release out within a weeks time. I’ll be updating this thread with link to the point release.
Thanks for posting.
Excellent, this is great news - thank you for following up on this and for the update. I think that will work for my team, I will reach out again if I hear otherwise for any reason. And the high performance lookup of ID and VersionStamp would be extra helpful, I would be interested in how that research pans out.
And sounds good about the SerialNumber vs. Product VersionStamp - that is what I figured and we will plan accordingly.
Talk again on this soon,
Would like to mention also to try and keep your load on your production database to a minimum. In our experience, deliveries and returns happen maybe 5 times per day at a super busy location. If your code runs once/day or a few times per day it should be running enough to grab your accurate data. If you need to do something more frequent you can mirror the database and run your code on the mirror.
Good to know - is mirroring the database something we can do on our end or would that require consult with Avontus? If we can do it I’ll follow up with our db/sys admins to get it done if we need it.
Really the database inserts/updates we are doing are limited to just Customers and Vendors, so I would not imagine the traffic to be that high for those entities.
But, we are grabbing several entities to integrate from Quantify to our ERP, namely Jobs, Products, Movements and Invoices. Does this throw a red flag in your mind that we will be hitting our prod database too much with selects if we run each of these entities, say, every hour?
You’ll want to get an experienced Dba to set up mirroring. For your purposes it sounds like an OK frequency. We had a customer that was running their code in a Windows Service 10x per second and in combination with a power BI script they brought the server to its knees. We just mention it so that you’re aware.
Hi Alex. Please find the following hyperlinks to pre-QA version of the interim build of next Quantify release.
Quantifyx64.exe (90.4 MB)
QuantifyWeb.exe (90.1 MB)
//VersionStampList is key-value-pair list that may be used to fetch ID, VersionStamp pairs from any table with a VersionStamp column in an efficient manner
VersionStampList productVersions = VersionStampList.GetVersionList(VersionStampList.DataObjectName.Product);
VersionStampList serialVersions = VersionStampList.GetVersionList(VersionStampList.DataObjectName.SerialNumber);
VersionStampList orderVersions = VersionStampList.GetVersionList(VersionStampList.DataObjectName.Order);
//Version stamp in product list
ProductList products = ProductList.GetProductList(ProductType.All);
ProductListItem product = products.FirstOrDefault(p => p.PartNumber == "PART-011");
byte prodVersionOriginal = product.VersionStamp;
//Version stamp in serialized part list
SerializedPartList serials = SerializedPartList.GetSerializedPartList();
SerializedPartListItem serial = serials.FirstOrDefault(s => s.SerialNumber == "SERIAL-011");
byte serialVersionOriginal = serial.VersionStamp;
//Version stamp in order list
Guid bpID = BusinessPartner.GetBusinessPartnerByName("CORP-011").BusinessPartnerID;
OrderList orders = OrderList.GetOrderList(bpID, OrderTypeEnum.Both, ActiveStatus.Both, false);
OrderListItem order = orders.FirstOrDefault(o => o.Number == "ORD-011");
byte orderVersionOriginal = order.VersionStamp;
This is great news. Thanks so much for making this a priority and getting us a fix quickly.
To clarify - all I need to do is run these executables on the server where our Quantify-Dev client/instance is located, correct? Do they generate a wizard to walk you through it or is it sufficient to just run them, either from the command line or file explorer?
Apologies if these are basic questions. I did not set up our instance so I am less confident with system administration tasks involving Quantify.
Cancel the above, replace with these questions:
I see they are literally the QuantifyWeb and Quantify application, which I assume are the API and Client, respectively?
Is updating our instance as simple as just replacing the existing application files with these?
You should be able to update an existing installation or do a new installation with Quantify Client installer linked to in the thread.
Quantify Web is totally optional, only needed it you’re using remote connection as the selected option in Connection Settings in Login dialog.
Please note that since this is a pre-QA release, it is not recommended to update an existing production installation for production use.
Thanks for posting.
Good to know all the above - thank you for the clarification.
And yes, we were not intending to update our production instance with this at all, but that is a good callout just to make sure. We will wait until the actual release to update that instance.