Источник достоверных данных: одна таблица событий запасов только для добавления записей и справочник SKU; текущий перезаписываемый столбец остатков становится снимком для миграции, а не историей. Идентификаторы: канонический SKU, место хранения STORE, идентификаторы заказа, заказа на закупку и события. До запуска нормализовать пять альтернативных обозначений. Единица измерения — штука.
Основные поля. События: идентификатор, время и тип события, SKU, количество со знаком, место хранения, идентификатор связанной записи, источник, статус, автор записи, подтверждающие материалы, согласовавший и ссылка на исправляемое событие. Заказы: идентификатор заказа, канал, статус, SKU, количество, временные метки резервирования, отбора и отгрузки — без персональных данных клиента. Заказы на закупку: идентификатор, поставщик, SKU, количество, цена за единицу, статусы черновика, согласования, отправки, обещанной поставки и приёмки. Возвраты: ссылка, SKU, количество и результат проверки. Ошибку никогда не удалять — добавлять сторнирующее или исправляющее событие.
Состояния и расчёты: запас в наличии = начальный остаток + принятое + согласованные возвраты в запас − отгруженное и проданное через POS − повреждённое ± согласованные корректировки. Зарезервировано = оплаченные единицы в открытых онлайн-заказах, которые не отменены и не отгружены. Доступно = запас в наличии − зарезервировано. Ожидаемые поступления показываются отдельно и никогда не включаются в доступный запас. Доступность комплекта BND-01 = min(floor(доступно MUG-BLU / 2), доступно TEA-WHT); при оплате и отмене заказа комплекта соответственно резервировать и освобождать его компоненты. Блокировать приём онлайн-заказа или направлять его на ручную проверку, если доступный запас станет отрицательным. Таблица не может управлять оформлением заказа в интернет-магазине, поэтому это остаётся операционной мерой контроля и пробелом интеграции.
Ежедневно: импортировать события POS и заказов, проверять уникальность SKU и заказов, сверять открытые резервы, рассматривать исключения. Сотрудник составляет проект заказа на закупку; владелец согласует и отправляет его. Для суммы свыше 500 долларов это обязательно, а для меньшей суммы закупка также остаётся под контролем владельца, пока правила не изменятся. При приёмке записывать заказ на закупку, фактическое количество и дату; расхождения направлять в исключения, а не перезаписывать. Возвраты остаются в ожидании до проверки. Еженедельно бухгалтер сверяет рассчитанный запас в наличии с экспортом исходных систем и регистрирует расхождения; ежемесячная инвентаризация создаёт согласованные корректировки с указанием причины.
Повторный заказ: не выдумывать точки повторного заказа. На первом этапе панель помечает позиции для проверки владельцем с учётом спроса за шесть месяцев, текущих доступных и ожидаемых запасов и обещанных дат из писем. Для оценки надёжности собирать фактические даты отправки заказов на закупку и приёмки. Затем владелец выбирает правила срока поставки и страхового запаса. Тесты: продажа, резервирование и отмена, частичная отгрузка, повторный импорт, неизвестный SKU, расход комплекта, возврат повреждённого товара, частичная приёмка заказа на закупку, согласование суммы свыше 500 долларов и расхождение при инвентаризации. Для миграции нужны фактический пересчёт, карта альтернативных обозначений, фиксация открытых заказов и заказов на закупку, а также подписанный снимок начальных остатков.
ChatGPT
