Add search only fields to CreditMemo
, PurchaseOrder
, and WorkOrder
#565
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Both
Invoice
andCreditMemo
records (as well as many other records) use the same search fields for the returned basic results,TransactionSearchRowBasic
, so rather than repeat the fields for each record, extract them to a common module that can be shared between the respective records.Since the search module may cover multiple records, it's fields will overlap with some of the standard fields on each record, so defining search only fields is now a no-op if the search only field already exists on the record as a standard field (rather than erroring). Previously for invoices, we defined search only fields as only the fields that didn't otherwise exist as standard fields, but now we need to include those standard fields potentially as search only as well as they may not be standard fields on another record that uses the same module. For this reason, it's necessary to include the search module after defining all the standard fields, otherwise we'll error if we try to define a standard field if it's already been defined as a search only field.
At this point, I only have use for searching invoices and credit memos, so the module is only included on those records, but it's the same search fields that could eventually be included on
AssemblyBuild
,BinTransfer
,CashSale
, etc. records, all of which generally seem to fall under "transaction".Alternatively, I'm conflicted whether
search
should continue to be an action on the individual records, as it is now, or whether it'd be better off as a separate class, better mirroring how it works internally at NetSuite.For example,
Invoice.search
will return all transaction types (ie. invoice, credit memo, etc.) unless you add a criteria ontype
to limit to just invoices. Similarly,InventoryItem.search
will return all item types (ie. inventory, non-inventory, service, etc.) unless you add a criteria ontype
. AndCustomer.search
will return all customer stages (ie. lead, prospect, customer) unless you add a criteria onstage
. There's probably more examples that I haven't come across yet. This regularly surprises me.Furthermore,
Invoice.search
may include a credit memo in it's results, but the instance of that record will be of typeNetSuite::Records::Invoice
, since that's the record class you searched on, as opposed toNetSuite::Records::CreditMemo
, which is misleading.Taking it a step further,
Invoice.search
may include the individual lines of each invoice as well, unless you set your criteria to mainline only, and now each of those lines is an instance ofNetSuite::Records::Invoice
, but that's a bit of a stretch.One simple thought is that when you call
Invoice.search
, we could automatically add the criteria fortype
. This would align with the NetSuite UI where if you're looking at the list of invoices and click Search in the top-right, it defaults the resulting search to "Type: Invoice". Then we can guarantee all results fromInvoice.search
would actually be invoices and having them be instances ofNetSuite::Records::Invoice
would always be appropriate (though less so for the individual lines, unless we defaulted to mainline only, but that seems like a step too far).The downside there being you couldn't search across types, if you were so inclined, unless you searched on each separate class (ie invoice, credit memo, etc.) then combined them yourself. Perhaps a solution there is to have a class like
TransactionSearch
that you use, so now it's clear you're searching transactions generally, and if you want to narrow it down by type, you have to provide the criteria. Then the results could be instances of something likeTransactionSearchRow
, where we'd define the fields that could be returned aligning with NetSuite's TransactionSearchRowBasic. The downside there, however being given an instance of a result, it'd be on the developer to cast that into an instance of the proper record (ie.Invoice
) if they needed to do some updates, or perhaps the row instance offers some helper method to convert to the record. MaybeInvoice.search
could still exist, but just proxy toTransactionSearch
with the appropriate criteria for type?Those are just my thoughts on using NetSuite and this gem after a few years.