# Brickscout - Tech Report 4
###### tags: `BrickScout`
## 1. Sending condition on creating cart_builder makes no difference
We tested with 6 items. Payload that we used is following:

{
  "allowedOversales": 1.25,
  "sensitivity": 3,
  "entries": [
    {
      "ean": "4057296548255",
      "neededQuantity": 1,
      "condition": <condition>
    },
    {
      "ean": "4057296291021",
      "neededQuantity": 1,
      "condition": <condition>
    },
    {
      "ean": "4057296295623",
      "neededQuantity": 1,
      "condition": <condition>
    },
    {
      "ean": "4057296308149",
      "neededQuantity": 1,
      "condition": <condition>
    },
    {
      "ean": "4057296517862",
      "neededQuantity": 1,
      "condition": <condition>
    },
    {
      "ean": "4057296518159",
      "neededQuantity": 1,
      "condition": <condition>
    }
  ],
  "isoalpha3": "ITA"
}

First we tested with having condition set to `null`. Total price was 39 EUR
and shop allocation was as following:

Das_bunte_Steineparadies
-------------------------
black brick 2x4
black plate 1x2

BrickTakeover
-------------------------
Blue Brick 2x4
Pirate Cook
Karlof

GalaxyArmsGmbH
-------------------------
Lando Calrissian

Setting condition as `NEW` resulted in exactly the same response. And again,
price was 39 EUR.

Third test, we set condition to `USED`, and again both price and payload
were exactly the same. 39 EUR, and shop allocation described above.

## 2. Cart builder entries have no assigned condition
When fetching cart_builde entries, there is no way of knowing in which state
any of the items is. There is a field `lot_used` which seems promising, but it
has the value `false` regardless of what we send when creating cart builder.
So we suspect it's not really a condition of the item.


## 3. Adjusting shop sensitivity is now impossible (due to 2.)
Due to not returning item condition as described in #2 of this
document, adjusting cart_builder for shop sensitivity (accurately) is now
impossible because we have no way of knowing in which state given item is,
or if it was even reflected in cart builder, as described in bug #1.

Best we can do - and this is probably not desired behavior, is setting
condition on cart_builder price sensitivity adjustments to `null`.

## 4. Some of the fees are not serialized
Some of the amounts that should be of type `MoneyAmount` come in a nonsensical
format, with lots of data that is not needed, and some value artefacts.
Probably exported directly from backend models without serialization.
(`java.util.Currency` and `org.javamoney.moneta.FastMoney`)

{
    "currency": {
        "context": {
        "providerName": "java.util.Currency",
        "empty": false
        },
        "defaultFractionDigits": 2,
        "currencyCode": "EUR",
        "numericCode": 978
    },
    "number": 0.00000,
    "zero": true,
    "negative": false,
    "negativeOrZero": true,
    "positive": false,
    "positiveOrZero": true,
    "precision": 1,
    "scale": 5,
    "context": {
        "precision": 19,
        "amountType": "org.javamoney.moneta.FastMoney",
        "fixedScale": true,
        "maxScale": 5,
        "providerName": null,
        "empty": false
    }
}

## 5. Creating cart_builder directly from list makes no sense
User is prompted to select items from the wishlist to be passed to the cart
builder, creating the cart_builder directly from wishlist would break user
interaction - ie: user selected one item, and all items are added to the cart
builder.

Instead of creating cart_buidler from wishlist, much more needed endpoint is
creating cart from the cart_builder.