Database Change

Payment Term Changes

We have had several requests to expand the data fields in our payment term infrastructure. We will begin this process with some database changes to “apppaymentterm” rolling out tonight (2021-05-06) which will include the following:

  • Expand the “name” field from 30 characters to 100 characters
  • Add “description” field

We will roll out a subsequent API update to take advantage of these changes in the coming days. For now the fields will be present in the database, but unaccessible to users.

API Change

Background Processing – Part 4

On April 27, 2021 we will be rolling out auto-background processing on the following additional endpoint(s):

  • salesorder-issue
  • salesorder-unissue
  • returnorder-issue
  • returnorder-unissue

Please update your integrated applications accordingly whether that is to support checking order status before continuing processing or using the new header (X-Background-Processing) outlined here to prevent/force background processing. Just be aware of the potential for operations to fail on larger orders should you opt not to background process.

API Change

Auto-Work Expansion

Just over a year ago we added support for passing a tracking number in when auto-working an order in LOCATE. Over the last year LOCATE’s auto-work capabilities have grown substantially behind the scenes. These abilities have been exposed mostly through their use backing various service integrations such as ShipStation which we added partial fulfillment support to several months ago. Other features like line specific auto-working have actually been staples in the LOCATE code base, but we never exposed all these features to developers, until now.

The full list of changes that are being released include:

  • Addition of carrier_id and carrierservicelevel_id so you can provide all the shipping details rather than just the tracking number. As before when these two fields are not provided the order carrier_id and carrierservicelevel_id will be used on the cartons.
  • Site specific auto-work: Previously LOCATE would run auto-work exclusively at the site the calling user was set at. Now, you can optionally provide a site_id (the calling user must have access to the site) and the auto-work will run from this site without having to change the user’s current site. If no site_id is provided we still default to the calling user’s current site.
  • Line Specific (and optionally qty specific) auto-working: You can now optionally provide an array of objects containing transactionline_ids (e.g. salesorderline_id, purchaseorderline_id, etc.) and quantities when making an auto-work call to partially work order and/or lines on those orders. This offers developers far more control and use cases where auto-work can be leveraged in their integrated applications. If line_details are not provided we will work the whole order just as before.
  • Deprecated full_auto: During our review and enhancements to the auto-work endpoint we discovered that this parameter was no longer necessary and have removed it from the documentation. If full_auto is provided your call will succeed, but as before additional parameters (task_ids/transactionline details) will supersede working the whole order. When no additional parameters are provided the auto-work endpoint will attempt to work all lines of the specified order to the fullest extent possible.
  • Enhanced validation and documentation on /autowork endpoint.
API Change

Background Processing – Part 3

Tonight we will be rolling out auto-background processing on the following additional endpoint(s):

  • purchaseorder-issue
  • purchaseorder-unissue
API Change

Background Processing – Part 2

Tonight we will be rolling out auto-background processing on the following additional endpoint(s):

  • group-clone
  • useorder-issue
  • useorder-unissue
API Change Reports

Report Event Parameters and Report Asset Rate Limits

In an effort to help users properly configure report events (printer/email) we will be tightening up the validation for creating these bindings so that any report that a user wishes to be associated with an email or print event must have at least one required parameter. We have run into some problems where users are binding reports without any required parameters resulting in massive, unfiltered reports being printed or attached to outbound emails. That does not mean that a report can’t be custom developed to take in a required parameter and not use it, but this should only be done to achieve a specific outcome like attaching a static document to an outbound email or printing a company logo label for use on a box. These uses cases have a finite report length (single page, etc.) and will not cause any load problems like reports that generate massive amounts of labels, pages, or tables might.

In addition to this protection mechanism we are also introducing a rate limit between reports being generated and the fetching of assets (barcodes, images, etc.) by those reports. This will prevent massive reports from flooding requests for resources into servers when most likely the report was run in error or mis-configured when run. We have allocated a sufficient amount of throughput such that normal day to day use will not be impacted, but asset heavy reports will noticed a slow down in rendering speed to better balance access to servers by all users.

API Change

Background Processing

Over the last year as LOCATE’s customer base has grown and the nature of business conducted on LOCATE has changed we have started to see larger and larger orders being processed in LOCATE. Large specifically as it relates to the number of lines on orders. What used to typically range from 1-20 lines with an occasional 100 line order now averages in the 1-40 line range with occasional orders of 1000+ lines. Performing actions on these larger orders has become a bit of a problem given LOCATE’s strict 60 second processing window for API calls. These larger orders simply result in timeouts as the operations cannot be performed quickly enough. One current work around is to leverage CSV files and the “Order Action” import to background process these larger operations, but this is tedious for the user and developer alike. With tonight’s release, we are beginning an important change in the LOCATE code base…background processing.

LOCATE makes use of background processing in many places (e.g. syncing services, auto-work, vendor confirmations, vendor site operations, etc.), but we have shied away from using background processing on the more frequently used endpoints like issuance, unissuance, voiding, cloning, etc. Starting tonight LOCATE will begin using background processing dynamically, based on order line count, for the /transferorder endpoint. Specifically with the issue and unissue operations. When one of these operations is backgrounded LOCATE will return a 202 response in place of the usual 200 response. Since the operation is backgrounded and the model will not have changed the 202 response contains no content and serves purely as an indicator to the caller that LOCATE is working on the requested operation.

We selected the /transferorder endpoint as the starting place for this roll out as it represents a lower impact order type where we can test/verify this functionality in the coming days. If you are calling transferorder-issue or transferorder-unissue then you may have to make some changes to your code to keep it working as it is currently written. With this rollout we are introducing a new header that can be provided on your requests to tell LOCATE that you do not want it to background process the request. You can read more about the details in the “Background Processing” section on the Core API Features page. For all developers who’s code relies on LOCATE’s serial processing of their requests we recommend that you add the new header to your code now so that as we roll out this change to more endpoints your code will not be affected until you are ready to change it, but disabling background processing when using an operation on a larger order will still result in a timeout as it does now.

We will update the API Reference to include the 202 response code as endpoints are updated to the new standard, as well as post about the changes on this blog. This change will greatly improve the user experience as well as reduce un-necessary load on the LOCATE servers for requests that cannot complete in a timely fashion.


New API Reference URL

We have moved where we are hosting our API Reference (swagger) documentation. The developer site has been updated to point to the new URL and with tonight’s release we will redirect anyone trying to use the old URL to the new site.

We also consolidated many of the endpoints to shrink the overall list which will improve load times on the swagger page as well as keep like items more closely grouped together under their matched root endpoints.

API Change

Auto-work Pick Optimization and Enhancement

We have re-written the auto-work pick code to expand the functionality and improve performance. Previously, LOCATE would only auto-work pick lines for an order that were not attached to a pick or picks that contained only pick lines from the given order. This meant if you created a wave/mixed pick (a pick containing pick lines from many orders) and then auto-worked the order that lines from the order on that pick would not be completed. This is no longer the case. The new auto-work code processes pick data at the line level rather than the pick level. This gives us more flexibility in how picks are auto-worked. At the same time this shift of focus for the code offered up some nice performance enhancements resulting in significant processing time drops for larger picks.

API Change Database Change

Vendor Confirmation Split Multiplier Data Type Change + New Multiplier Validation

Tonight we will be changing the appvendorconfirmation.split_multiplier field from an integer to a decimal field. This is to bring the field in line with the datatype of the appworkorder.multiplier field. In conjunction with this change we will be re-opening the use of decimal multipliers on work orders and vendor confirmations under certain conditions. If all parts on a work order or vendor confirmation (excluding services) are stocked in non-countable UOM types then you will be permitted to use decimal multipliers on these two documents. If the transaction contains even one part that is stocked in a countable UOM type (excluding services) then you will not be permitted to use a decimal multiplier or could be prevented from adding the part to the order if it already has a decimal multiplier applied.