Override Price & Cost feature like Back Office

Mingle Card: 5787 https://liquidframeworks.mingle.thoughtworks.com/projects/back_office/cards/1161?referrer%5Bq%5D=type%3Afeature+price&referrer%5Bq_type%5D=&referrer%5Bquery_id%5D=q_81362c282be8440ca7c941eaf2d2eb13&referrer%5Brank%5D=2&referrer%5Bsize%5D=19&referrer%5Bts%5D=10%2F24%2F18+13%3A56%3A36

Test Plan

Stories

{{ table query: SELECT Number, Name, Owner, Status, 'Story Points' WHERE Type = Story and Feature = THIS CARD ORDER BY Status }}

This depends on a new feature for Field Updates: #6220 and #6221

Analysis

A central UI for building a common criteria for field overrides would link the mobile feature to the back office feature.

Replace the Ticket Item Price with an Override Price value from the first case which matches:

Example:

For all cases:
  1. Ticket Item's Region Code matches an Override Region Code
  2. Ticket Item's Catalog Item matches an Override Catalog Item

Case 1:
  3. Ticket Item's Customer matches Override's Customer
  4. Ticket Item's Haul From Location matches an Override Haul From Location
  5. Tickets Item's Haul To Location matches an Override Haul To Location

Case 2:
  6. Ticket Item's Customer matches an Override Customer
  7. Ticket Item's Haul To Location matches an Override Haul To Location

1 AND 2 AND ((3 AND 4 AND 5) OR (6 AND 7))

This would be represented as in two ways:

as a SOQL predicate.
as a Lookup Action.

SOQL output:

FX5\_\_Catalog\_Item\_\_c = $FX5\_\_Catalog\_Item\_\_c AND Office\_Region\_Code\_\_c = $Office\_Region\_Code\_\_c AND (
(FX5\_\_CustomerAccount\_\_c = $FX5\_\_CustomerAccount\_\_c AND Haul\_From\_Location\_\_c = $Haul\_From\_Location\_\_c AND Haul\_To\_Location\_\_c = $Haul\_To\_Location\_\_c) OR
(FX5\_\_CustomerAccount\_\_c = $FX5\_\_CustomerAccount\_\_c AND Haul\_To\_Location\_\_c = $Haul\_To\_Location\_\_c))

Field Update Criteria and Action

AND(
  Has\_Quote\_Item\_\_c == false,
  Lock\_Override\_Engine\_\_c ==false,
OR(
  ISCHANGED(Office\_RegionCode\_\_c),
  ISCHANGED(Haul\_From\_Location\_\_c),
  ISCHANGED(Haul\_To\_Location\_\_c)
))

The resulting action:

  BLANKVALUE(
    ${FIRST('Override\_\_c', 'Office\_RegionCode\_\_c+FX5\_\_Catalog\_Item\_\_c+FX5\_\_CustomerAccount\_\_c+Haul\_From\_Location\_\_c+Haul\_To\_Location\_\_c',
         \[Office\_RegionCode\_\_c, FX5\_\_Catalog\_Item\_\_c, FX5\_\_CustomerAccount\_\_c, Haul\_From\_Location\_\_c, Haul\_To\_Location\_\_c\], Price\_\_c)},
      BLANKVALUE(
        ${FIRST('Override\_\_c', 'Office\_RegionCode\_\_c+FX5\_\_Catalog\_Item\_\_c+FX5\_\_CustomerAccount\_\_c+Haul\_To\_Location\_\_c',
                        Office\_RegionCode\_\_c + FX5\_\_Catalog\_Item\_\_c + FX5\_\_CustomerAccount\_\_c + Haul\_To\_Location\_\_c, Price\_\_c)},
        BLANKVALUE(
          ${FIRST('Override\_\_c', 'Office\_RegionCode\_\_c+FX5\_\_Catalog\_Item\_\_c+FX5\_\_CustomerAccount\_\_c+Bill\_To\_Location\_\_c+Bill\_To\_Site\_Type\_Id\_\_c',
                        Office\_RegionCode\_\_c + FX5\_\_Catalog\_Item\_\_c + FX5\_\_CustomerAccount\_\_c + Haul\_To\_Location\_\_c + '2', Price\_\_c)},
          FX5\_\_PBI\_Price\_\_c
      ))))

Operational Limitations

Traversals into Override Lookups would not work.
1. The sync currently won’t support it. Instead of a straight object sync which would tread overrides as a lookup, we would have to scan the override configurations and generate a projection map to query for all of the “right” data to make the config work.
2. It’s very hard to write a UI which makes the config “easy”. Also this can lead to confusion with the user having to KNOW the schema well enough to navigate to what he/she wants. Cumbersome.
3. The fix for this would be to float important values for the config in the Override. For lookups we never eval calculated fields so the calculated value was be treated as a raw value.
We don’t support calculations for either side of the comparison.
1. For simplicity when parsing the FX_FIND method from #6220 we do not support calculations for either the index’s or the index value. This would require us to fire up a calc parser during the preprocessing.
2. I have not seen any case where this happens in current implementations.

githubbob42 / mingle2github2