Hi K,

Right now only units on hand can be committed to orders. I’ve seen some documentation for 2020.1 release having some features regarding somewhat “tying” off inbound units to open orders, but I’m not entirely sure how that will work. My guess is they will behave like special purchase orders at that point, but hopefully without all the pains of the special purchase orders.

getFieldText should work

I believe you can run a search on searches. Not sure what all comes back, but might get you going in the right direction.

You’re doing “Add” not “Update” in the second step of the import, correct?

While you want to “update” inventory quantities, you are not “updating” any existing transaction. You want to make new Adjustments so you’ll need to be sure you’re selecting “Add”, as in “add a new inventory adjustment”.

I haven’t ever seen a maximum in any documentation. I have seen accounts with hundreds of custom item fields though and they worked fine without issue. As for transaction fields, I’ve also seen accounts with probably at least 100 custom fields on them, once again with no issue.

There was a thread a few weeks back in NS Pros Slack channel about someone wondering if adding additional fields would add to total memory. It might, but I believe the difference would be negligible. The overall count of records being more cumbersome than the number of fields themselves.

The biggest thing is with hundreds of fields, I would definitely consider having someone manage your forms, as user experience can degrade pretty quickly with busy forms of custom fields scattered all over the place.

Chrome extension Dark Reader does a decent job, but a few pages can look a little strange.

If you want it simply based on a field like purchase price, you could run a saved search with a formula field along the lines of:

{effectiverate} – {item.cost}

In this event, you’d be using the purchase price as your cost. You can also replace that with average cost, last purchase price, etc.

You can then group by item, and sum over these values or average to get an average margin. All kinds of options in terms of reporting different values. A few more to consider:

• Get total margins by location or some type of item grouping
• Modify the formula to return percentages and get average margins by a grouping
• Use CASE WHEN SQL statements in the formula to bucket the margins by month/quarter/year and show totals in different time buckets and changes over time

Just some ideas.

I don’t believe there is a setting for this, but it could be achieved with a client script unchecking them on pageInit trigger.

The code would look something like:

var rec = context.newRecord;

var lineCount = rec.getLineCount({sublistId: 'item'})
for(var i = 0; i < lineCount; i++){

rec.selectLine({sublistId: 'item', line: i});

rec.setCurrentSublistValue({sublistId: 'item', fieldId: 'itemreceive', value: false});

rec.commitLine({sublistId: 'item'});

}

Hope that helps!

These are the context.userEventTypes available to script against:

• APPROVE
• CANCEL
• CHANGEPASSWORD
• COPY
• CREATE
• DELETE
• DROPSHIP
• EDIT
• EDITFORECAST
• EMAIL
• MARKCOMPLETE
• ORDERITEMS
• PACK
• PAYBILLS
• PRINT
• QUICKVIEW
• REASSIGN
• REJECT
• SHIP
• SPECIALORDER
• TRANSFORM
• VIEW
• XEDIT

Unfortunately I don’t see anything that would line up with the scenario you have. As weird as it is, I’ve run into things like this before where I just can’t get a UE to fire on certain events.

Normally, I work around this by running a scheduled script looking for them being created instead and triggering that way. Not ideal, but not much else you can do I guess.

Also, if you load the lodash library in, you can use the _.find function. In general, that whole library can be very useful.