epistemophiliac/frappe_docker
1
0
Fork 0
mirror of https://github.com/frappe/frappe_docker.git synced 2026-06-22 15:55:09 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 4

docs: fix spec issues — ms_id prefix, source_type update, ms_order_state validation

Browse source
This commit is contained in:
abounoone 2026-03-20 03:27:10 +00:00
parent 0f6efacf11
commit cc3e5f6e6a
1 changed files with 36 additions and 16 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

52
docs/superpowers/specs/2026-03-20-moysklad-orders-sync-design.md
View file

@ -18,27 +18,41 @@
|------|-----|----------------------| |------|-----|----------------------|
| `ms_order_state` | Data | `"Подтверждён"` | | `ms_order_state` | Data | `"Подтверждён"` |
### Picking List — новое поле Поле помечается `reqd: 1` и `default: "Подтверждён"` в DocType, чтобы пустое значение было исключено на уровне схемы. Дополнительно в коде: если значение пустое — использовать `"Подтверждён"` как runtime-fallback.
### Picking List — новые поля
| Поле | Тип | Значение | | Поле | Тип | Значение |
|------|-----|---------| |------|-----|---------|
| `source_type` | Select | `"Move"` / `"Order"` | | `source_type` | Select | `"Move"` / `"Order"` |
Для существующих записей `source_type` не проставляется (остаётся пустым — UI трактует как Move). **Уникальность `ms_id`:** текущий `unique: 1` на поле `ms_id` снять. Вместо этого хранить `ms_id` с префиксом типа:
- Перемещения: `move:{uuid}`
- Заказы: `order:{uuid}`
Это исключает коллизии UUID между разными типами сущностей МС.
## Логика синхронизации ## Логика синхронизации
### `sync_picking_list()` — изменения
- При **создании** новой записи проставлять `source_type = "Move"` и `ms_id = "move:{uuid}"`
- При **обновлении** существующей записи — также проставлять `source_type = "Move"` если поле пустое (backfill)
### `sync_picking_orders()` ### `sync_picking_orders()`
1. Читает `ms_order_state` из `Picking Settings` (fallback: `"Подтверждён"`) 1. Читает `ms_order_state` из `Picking Settings`; если пусто — использует `"Подтверждён"`
2. Тянет `customerorder` из МС: 2. Тянет `customerorder` из МС:
``` ```
GET /entity/customerorder GET /entity/customerorder
expand=state,positions.assortment,positions.assortment.uom expand=state,store,positions.assortment,positions.assortment.uom
limit=100 limit=100
order=moment,desc order=moment,desc
``` ```
`store` обязательно включён в expand — иначе объект склада придёт как stub без `name`/`id`.
3. Фильтрует на клиенте: `order["state"]["name"] == ms_order_state` 3. Фильтрует на клиенте: `order["state"]["name"] == ms_order_state`
4. `to_warehouse` берётся из `store` объекта заказа (склад отгрузки); `from_warehouse` — пустой 4. `to_warehouse` берётся из объекта `store` через существующий `_extract_store_id()`; `from_warehouse` — пустой
5. Создаёт/обновляет `Picking List` с `source_type = "Order"` по той же логике что `sync_picking_list()` 5. `ms_id` сохраняется с префиксом `"order:{uuid}"`
6. При **создании** — `source_type = "Order"`. При **обновлении** — `source_type` всегда перезаписывается значением `"Order"` (поле не является иммутабельным).
**Производительность:** фильтрация по статусу происходит на клиенте после получения всех страниц (МС API не поддерживает фильтр по `state.name` напрямую без UUID состояния). Лимит: не более 1000 заказов за одну синхронизацию (10 страниц по 100) — это осознанный компромисс.
### `sync_all()` — новая публичная функция (`@frappe.whitelist`) ### `sync_all()` — новая публичная функция (`@frappe.whitelist`)
Вызывает последовательно `sync_picking_list()` и `sync_picking_orders()`, возвращает суммарный результат: Вызывает последовательно `sync_picking_list()` и `sync_picking_orders()`, возвращает суммарный результат:
@ -46,21 +60,27 @@
{"status": "ok", "moves": {"created": N, "updated": N}, "orders": {"created": N, "updated": N}} {"status": "ok", "moves": {"created": N, "updated": N}, "orders": {"created": N, "updated": N}}
``` ```
Существующая `sync_picking_list()` при создании новых записей проставляет `source_type = "Move"`. ## Исправление существующего бага
В `add_items_from_picking_list()` строка 462 содержит ссылку на неопределённую переменную `added_rows` вместо `added_row_names`. Исправить в рамках этой задачи, иначе функция упадёт с `NameError` при первом же вызове.
## API: `get_picking_list_items()`
Добавить опциональный параметр `source_type`:
- `source_type=None` — вернуть все записи (включая NULL из legacy)
- `source_type="Move"` / `"Order"` — фильтровать по значению; NULL-записи при `"Move"` **включаются** (обратная совместимость)
Добавить `source_type` в список возвращаемых полей (`fields`), чтобы UI мог рендерить колонку "Тип".
## UI ## UI
В попап-диалоге выбора позиций: В попап-диалоге выбора позиций:
- Добавить колонку **Тип** (`source_type`): отображает "Перемещение" / "Заказ" - Добавить колонку **Тип**: отображает "Перемещение" (Move и NULL) / "Заказ" (Order)
- Добавить фильтр по типу: табы или кнопки **Все / Перемещения / Заказы** - Добавить фильтр по типу: табы или кнопки **Все / Перемещения / Заказы**
- Логика добавления позиций в `Picking Document` — без изменений - Логика добавления позиций в `Picking Document` — без изменений
## Что не меняется ## Прочее
- Структура `Picking List Item`
- Логика `add_items_from_picking_list()`
- Логика `get_picking_list_items()` — добавить опциональный параметр `source_type` для фильтрации
- Статусная машина Picking List (Draft → Partial → Added)
## Ограничения - Поле `ms_date` в UI показывает "Дата перемещения" — для заказов это несточное название. Принимаем как допустимое упрощение: переименование метки выходит за рамки задачи.
- Фильтрация по статусу происходит на стороне клиента (МС API не поддерживает фильтр по `state.name` напрямую через query params без знания UUID состояния) - Статусная машина Picking List (Draft → Partial → Added) — без изменений
- `from_warehouse` у заказов не заполняется - Структура `Picking List Item` — без изменений