OBPIH-6278 Do not allow uom qty different than 1, when chosen uom is …#4570
OBPIH-6278 Do not allow uom qty different than 1, when chosen uom is …#4570awalkowiak merged 2 commits intorelease/0.9.1from
Conversation
…Each for the PO items import
| UnitOfMeasure uom = uomParts.length > 1 ? UnitOfMeasure.findByCodeOrName(uomParts[0], uomParts[0]) : null | ||
| orderItem.quantityUom = uom | ||
| BigDecimal qtyPerUom = uomParts.length > 1 ? CSVUtils.parseNumber(uomParts[1], "unitOfMeasure"): null | ||
| if (uom?.id == 'EA' && qtyPerUom != 1) { |
There was a problem hiding this comment.
I think it is worth moving 'EA' to Constants.groovy as UOM_EACH_ID or EACH_ID
There was a problem hiding this comment.
yeah, I always feel uncomfortable hard-coding strings, but I thought you guys would treat it as an overkill in that case 🙈 but I'm happy we are on the same page
There was a problem hiding this comment.
I agree with converting string literals to constants in most cases, especially for things like PKs. The exception is when it makes it much more difficult to read the code. For example, if I need to go to the constants file in order to figure out what the code is doing then that would be worse then using the string literal.
But this rule should be in our coding conventions and perhaps should become a linter rule as well.
There was a problem hiding this comment.
And in this particular case, I would prefer UOM_EA_ID over EA_ID because the latter would require me to go to the constants.groovy to figure out what's going on. So hopefully that was what we went with.
There was a problem hiding this comment.
@jmiranda Kacper went with even more descriptive -> UOM_EACH_ID
4 participants
…Each for the PO items import