1. 注文詳細画面から倉庫を指定する場合に関して
1.1. 実在庫が不足している場合にNGとするか否か
1.1.1. NGにすると運用が厳しい
1.1.2. 一旦マイナスでも出荷してしまって後追いで在庫を正しくするケースはある
1.2. DB的な話
1.2.1. 登場人物
1.2.1.1. logistics_inventory
1.2.1.1.1. backorder_quantity
1.2.1.1.2. quantity
1.2.1.1.3. available_quantity
1.2.1.2. order_component_allocation
1.2.1.2.1. quantity
1.2.1.3. order_component
1.2.1.3.1. lacked_warehouse_id
1.2.1.3.2. lacked_quantity
1.2.2. 在庫不足時（現状）
1.2.2.1. logistics_inventory
1.2.2.1.1. backorder_quantity： 注文数が入る ( 5 )
1.2.2.1.2. quantity： 出荷前は変動なし ( 2 )
1.2.2.1.3. available_quantity： quantity - backorder_quantity ( -3 )
1.2.2.2. order_component_allocation
1.2.2.2.1. quantity： 足りてる在庫数分のみ ( 2 )
1.2.2.3. order_component
1.2.2.3.1. lacked_warehouse_id： 不足分を引き当てた倉庫のIDが入る
1.2.2.3.2. lacked_quantity： 不足してる数が入る ( 3 )
1.2.3. 在庫不足時（あるべき姿）
1.2.3.1. logistics_inventory
1.2.3.1.1. backorder_quantity： 注文数が入る ( 3 )
1.2.3.1.2. quantity： 出荷前は変動なし ( 2 )
1.2.3.1.3. available_quantity： quantity - backorder_quantity ( -1 )
1.2.3.2. order_component_allocation
1.2.3.2.1. quantity： 足りてる在庫数分のみ ( 3 )
1.2.3.3. order_component
1.2.3.3.1. lacked_warehouse_id： 不足分を引き当てた倉庫のIDが入る
1.2.3.3.2. lacked_quantity： 不足してる数が入る ※事実上いらなくなる？
1.2.3.4. 在庫が足りない状態で出荷された注文明細がどれかを判断できなくなるのでは？
1.2.4. 在庫不足時（あるべき姿）v2
1.2.4.1. logistics_inventory
1.2.4.1.1. backorder_quantity： 注文数が入る ( 3 )
1.2.4.1.2. quantity： 出荷前は変動なし ( 2 )
1.2.4.1.3. available_quantity： quantity - backorder_quantity ( -1 )
1.2.4.2. order_component_allocation
1.2.4.2.1. quantity： 足りてる在庫数分のみ ( 2 )
1.2.4.3. order_component
1.2.4.3.1. lacked_warehouse_id： 不足分を引き当てた倉庫のIDが入る
1.2.4.3.2. lacked_quantity： 1
1.2.4.4. 在庫が足りない状態で出荷された注文明細がどれかを判断できなくなるのでは？
2. ロットがわからないときはどうするべき？
2.1. デフォルトロットに一旦割り当てる
2.1.1. デフォルトロットで在庫管理してる場合に、混ざってわかりづらくならないか？
2.1.2. ロット管理してる場合は、デフォルトロットを在庫管理に利用していない前提