I know we've done that in some places, but I don't like the naming like getIs.
Booleans should be named as isSomething.
Moreover, those don't have to be marked transients anymore, so you could just have a method isInvoicable().

Yeah, but the naming convention with get, allows us to use the .getIsEncumbered() in this way: .isEncumbered, so I prefer this groovy syntactic sugar

I don't see anything bad in using .isEncumbered() vs forcing to access a property via the field name (isEncumbered). I feel like naming booleans using getIs, getHas is an anti-pattern we should avoid.
https://rules.sonarsource.com/java/tag/convention/RSPEC-2047/

This is groovy, not Java 😄
The rule that you send is another case. They say that we should use hasBar, not getBar

yeah, and why should we use getBar for a boolean field?

not getBar, but getIsBar, and then we can use it isBar

I will repeat it again, and you will do whatever you want - getIs feels like antipattern, and I don't see anything wrong in using isBar() in this case.

I'm used to seeing fields like:

invoiceable
encumbered

with getters and setters like

isInvoiceable
setInvoiceable
isEncumbered
setEncumbered

From the groovy docs: https://groovy-lang.org/objectorientation.html#_property_naming_conventions

...generated getters and setters will have a name formed by capitalizing the property name and adding a get or set prefix (or optionally "is" for a boolean getter)... isEmpty might be the getter method name for a property named empty.

So with that setup in Groovy we could do boolean isOrderInvoiceable = order.isInvoiceable() as Kacper says. That's my personal preference but if you disagree Alan feel free to do as you wish.

Java beans use the same convention.

So since we keep having this conversation

#4266 (review)

... let's just use the java/groovy convention from now one.

So no more "is" prefix in the property name.

Aside: All I really care about is that I want to use Groovy's implicit getter method

if (order.invoiceable)

over the explicit getter methods

if(order.getInvoiceable())

or

if(order.isInvoiceable())

The problem with getIs is that the property itself would be named with the is prefix, e.g. isInvoiceable instead of invoiceable.
https://stackoverflow.com/a/5322730

Your field should not be called isCurrent in the first place. Is is a verb and verbs are inappropriate to represent an Object's state. Use an adjective instead, and suddenly your getter / setter names will make more sense:

same as above

I think you need javadocs to start with /** (two asterisks) to have them work correctly in IDEs and other tools. Good job with the documentation here though!

What if the order adjustment is not tied to any order item? This is possible too

Should this be also order.isPlaced() to be considered encumbered or not?

what do these mock order items give us?

I added those mocked order items, because we have to have at least one order item fulfilling the tested case, so I am testing if one item of those three matches the tested condition.

I guess my question was more what kind of values do these mocks return? Do they have quantity 0?

what about testing the scenario where Order.stats == PLACED? then you would be able to generate an invoice right?

Order status cannot be placed. The available options are:

[PENDING, COMPLETED, CANCELED, BACKORDER]

that's OrderItemStatusCode right? I meant OrderStatus

shouldn't this condition return true? You have an un-invoiced adjustment that has no associated order items

that's interesting, why this test doesn't fail

Oh, got the reason, I didn't take order status into account (orderAdjustment.isInvoiceable takes into account the fact if order is placed)

I think the first point is misleading.

What is an invoiceable item?
a shipped item or a placed adjustment; any placed adjustment is pulled as invoiceable on the partial final invoice generated (but it can be removed or edited) or a canceled line

Order adjustment should be invoiceable if the order has a prepayment invoice and is placed.
Order item should be invoiceable if it has prepayment invoice and:

1. is partially shipped (only this partial quantity not yet invoiced is invoiceable)
2. items canceled that are not yet invoiced

Imho there is no need to check in order item is invoiceable if it has NotInvoicedAdjustment, I think the order adjustments should be separated from order items and checked as it is written above.

(to be confirmed)