Один заказ может содержать несколько товаров, а один товар — входить в сотни заказов. Если хранить такую связь только списком названий, становится трудно указать количество, цену и скидку каждой позиции. В Airtable для этой задачи подходит промежуточная таблица: каждая её запись описывает конкретный товар в конкретном заказе.

Разделите сущности до заполнения базы

Airtable поддерживает связанные записи и отношения «один ко многим» и «многие ко многим». Промежуточная таблица нужна, когда у самой связи есть свойства. В модели продаж это «Заказы», «Товары» и «Позиции заказа». В последней хранятся ссылки на один заказ и один товар, а также фактически заказанное количество.

Не используйте название товара как единственный идентификатор. Два похожих комплекта могут иметь одинаковое коммерческое название, но разные артикулы. Сохраните устойчивый внутренний код. Если заказ пришёл из внешней системы, полезно отдельно хранить её номер заказа и идентификатор строки, чтобы повторная загрузка не создавала ещё одну покупку.

Сохраните цену именно на момент продажи

Текущая цена из каталога и фактическая цена в заказе отвечают на разные вопросы. Если отчёт всегда подставляет сегодняшнюю цену товара, изменение каталога способно исказить представление о прошлой продаже. Поэтому цену согласованной покупки следует сохранять в позиции заказа отдельным значением, а текущую каталожную цену показывать лишь для сравнения.

Аналогично определите, где хранится скидка: уже включена в цену единицы или вычитается отдельной суммой. Не смешивайте эти схемы в одной колонке. При дальнейшем расчёте прибыли пригодится разбор соединения продаж с себестоимостью: соответствие артикула ещё не решает вопрос о дате применённой цены.

Проверьте модель на небольшом наборе

Создайте условный заказ с двумя разными товарами и второй заказ с повторной покупкой одного из них. Затем измените цену этого товара в каталоге. Исторические суммы первых заказов должны остаться прежними, если именно это правило принято в вашей модели. Этот тест выявляет ошибочную зависимость до загрузки большого архива.

Добавьте возврат одной единицы и уточните, как он учитывается: отдельным событием или изменением статуса позиции. Не стирайте исходное количество без следа, если по нему уже строился отчёт. Проверьте также пустую ссылку на товар и случайный выбор нескольких товаров в одной позиции; эти ситуации должны попадать в проверку качества данных.

Собирайте отчёт на правильном уровне

Когда позиции объединяются с заказами, общая сумма заказа может повториться в каждой строке. Её нельзя бездумно суммировать после такого разворота. Этот риск подробно показан в разборе дублирования суммы при раскрытии списка. В отчёте по товарам суммируйте значения позиций, а число заказов считайте по уникальному идентификатору.

Зафиксируйте схему базы и правила изменения исторических данных в инструкции для команды. Менеджер должен понимать, где исправлять ассортимент, а где фактическую покупку. Правильная структура связей не заменяет учётную систему, но делает рабочую таблицу проверяемой и уменьшает вероятность того, что обновление карточки товара незаметно изменит прошлые результаты продаж.