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 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.

Database Change

Order Discount/Fee Pre-Distribution

One of the more subtle, and often overlooked aspects of discounts and fees is how they are distributed. In LOCATE line level discounts/fees are calculated at the unit level (meaning the amount of the discount or fee is subject to the qty on the line as a multiplier). While order level discounts/fees are a flat amount. Line level fees have a rather granular level of control when it comes to representing how an order is being modified with discounts/fees. However, some eCommerce platforms offer even more flexibility, such as the ability to have an order level discount/fee that only applies to specific products on the order, or perhaps only a portion of the discount might apply to one line while a larger portion might apply to a second line. These subtle features create problems when LOCATE doesn’t have this data as it means when orders are partially shipped or partial returns are issued LOCATE and the eCommerce platform might not agree on exactly how much of an order level discount/fee to apply to an invoice or return order.

Shopify recently added discount details to their API allowing developers this level of insight in how their own discounts are being applied across an order. In our endless pursuit of ever more accurate data we are making a similar enhancement to LOCATE. We have added a new service_id field to the cfgtransactionlinediscountlinkage and cfgtransactionlinefeelinkage tables that we will begin using in the next few weeks. LOCATE’s Shopify integration will be updated to pull in this discount metadata and store exactly how Shopify distributes its discounts in these tables referencing the service as the source/creator of the distribution.

On top of this, LOCATE itself will be updated to pre-distribute order level discounts/fees at order issuance using the same linkage tables. Our distributions will not store a value in this new service_id field. So rather than trying to mirror the math of how order level discounts/fees are distributed over order lines, you will have the exact figures stored in an easy to access relational table. LOCATE’s code base will be updated to use these pre-determined discount/fee distributions throughout the order life cycle in an effort to provide more transparency, clarity, and ease when working with discounts/fees in reports. We will provide additional updates as these changes are released and data starts flowing into these tables.

These linkage tables are currently used to bridge the distribution of discounts/fees from order to invoice. This functionality will not change, but we will be adding additional records about pre-distribution from the order to the order. If you have any reports that presume that all data in the linkage table is for invoices these will need to be updated.