# `PhoenixKitWarehouse`
[🔗](https://github.com/BeamLabEU/phoenix_kit_warehouse/blob/0.4.0/lib/phoenix_kit_warehouse.ex#L1)

PhoenixKit module: multi-warehouse stock scope, stocktakes, transfers with
cancel reverse-posting, deficit control with min-stock settings, turnover
report, internal orders, supplier orders, goods receipts, and goods issues.

All four sibling packages are hard dependencies in `mix.exs` — none is
declared `optional:`, so all four are always compiled in:

  * `phoenix_kit_catalogue` — warehouse only ever tracks catalogue items.
  * `phoenix_kit_locations` — every document carries a `location_uuid`
    resolved through it.
  * `phoenix_kit_billing` — currency formatting for unit values, via a
    compile-time `import` of `CurrencyDisplay.currency_compact/1`.
  * `phoenix_kit_comments` — six form LiveViews `use
    PhoenixKitComments.Embed`. A `use` is macro expansion at compile time,
    so this one can be neither guarded nor made optional; that is why
    `mix.exs` floors it at 0.2.8 rather than 0.2.

A hard *package* dependency is not the same thing as a required *module*.
`required_modules/0` lists only `"catalogue"` and `"locations"` — the two
whose PhoenixKit modules a host must actually have enabled. Billing is
never enablement-checked at all (its component is imported, not called
conditionally), and comments is checked at runtime but not required:
`PhoenixKitWarehouse.Comments.available?/0` gates every comments call on
`PhoenixKitComments.enabled?/0`, and all six form LiveViews assign
`comments_available?` from it, so a host that has the comments module
installed but switched off simply renders no threads.

Documents link to host-owned records (a sub-order, a top-level order, or
anything else a consuming app wants to link) through the generic
`PhoenixKitWarehouse.SourceKinds` registry rather than a direct dependency
on any specific "order" concept — see that module's docs.

# `translatable_labels`

```elixir
@spec translatable_labels() :: [String.t()]
```

Pins every label this module declares as a gettext msgid.

`permission_metadata/0`, `admin_tabs/0`, `hidden_crud_tabs/0` and
`settings_tabs/0` declare their labels as plain string literals, so
`mix gettext.extract` never sees this file. PhoenixKit translates them at
render time through each declaration's `gettext_backend`/`gettext_domain` —
but only if the msgid exists in this module's own catalogue.

Until this function existed, the tab labels were in `default.pot` purely by
coincidence: `Web.WarehouseHeader` and `Web.TurnoverReportLive` happen to use
the same English strings, and their `gettext` macro calls are what the
extractor found. Rewording either file would have silently reverted eight
admin tabs to English with no compile error and no failing test.

`dgettext_noop/2` registers the msgid and returns it unchanged — nothing here
runs at request time.

---

*Consult [api-reference.md](api-reference.md) for complete listing*