Purchase Order modified/version stamp field

4

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?

Thanks,
Alex

5

Hi Alex.

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.

6

Hello,

Thank you for the response, this helps me understand the capabilities of the API.

Just a few follow-up questions:

  1. 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?
  2. Will the VersionStamp property be available for both of these entities in the upcoming release?
  3. Do you have an estimate for when this release will be available to us?

Thanks again for your help with this.
Alex

7

Hello,

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,
Alex

8

Hi Alex.

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.

9

Hello,

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.

Alex

10

Hello,

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.
Thanks,
Alex

11

Hi Alex.

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.

12

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,
Alex

13

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.

14

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?

15

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.

16

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

//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);

ProductList

//Version stamp in product list 
 ProductList products = ProductList.GetProductList(ProductType.All);
 ProductListItem product = products.FirstOrDefault(p => p.PartNumber == "PART-011");
 byte[] prodVersionOriginal = product.VersionStamp;

SerializedPartList

//Version stamp in serialized part list
 SerializedPartList serials = SerializedPartList.GetSerializedPartList();
 SerializedPartListItem serial = serials.FirstOrDefault(s => s.SerialNumber == "SERIAL-011");
 byte[] serialVersionOriginal = serial.VersionStamp;

OrderList

//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;
17

Hello,

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.

Thanks,
Alex

18

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?

19

Hi Alex.

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.

20

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.

Alex

21

Hello,

Just one final follow-up on this - I was able to get the updated code and it will definitely work for us, which is great news.

I wanted to clarify where Quantify will be moving towards in the future in one respect, however. I saw that the VersionStamp was added on the ProductList (and OrderList and SerialNumberList), and accordingly the respective ListItems.

However, the actual objects of each of these do not have the VersionStamp (e.g. Product and Order), whereas other data entities (e.g. Movements) have VersionStamp on both the actual object and ListItem. And other data entities, like StockingLocations, have VersionStamp on the actual object, but not the ListItem.

Is there going to be a standard for where this information will be located in future versions, e.g. on both the actual object on the list item, or one vs. the other, and a recommended approach for retrieving it? I just want to do what I can to make my code future-proof and follow best practices.

Again, this fix will work for us, so not a time-sensitive issue - this is mainly for my curiosity and designing.

Thanks,
Alex

22

Hi Alex.

We made a conscious decision to include the added VersionStamp properties in this release in the List/Item objects.
VersionStamp in editable objects like Product and StockingLocation existed primarily for the benefit of our developers. These may exist independent of the List objects more geared towards the internal usage needs similar to keeping VersionStamp in Product Private as to keep it hidden from specific derived classes.
Going forward, it is planned to expose VersionStamps on all List/Item objects, where one is defined in the database. Also, VersionStampList will be kept to up-to-date for fetching (Primary-Key-ID, VersionStamp) => (Key, Value) in an efficient manner for all tables with a VersionStamp.

Thanks for posting

23

Sounds good, that is all good to know. Thank you for the clarification on this!