Как организовать учет заказов маркетплейсов в 1С 7.7: выбор между изменением табличной части и созданием новых документов

Работа с маркетплейсами (Wildberries, Ozon, Яндекс.Маркет) диктует новые требования к складскому и финансовому учету, даже если ваша компания использует проверенную временем платформу 1С:Предприятие 7.7. Основная сложность заключается в необходимости отслеживать каждый конкретный заказ покупателя в рамках одной массовой отгрузки. Разберем, как правильно реализовать хранение «Номера заказа» и «Стикера» в типовых документах РасходнаяНакладная и Счет.

Постановка задачи и анализ ситуации

Рассмотрим стандартную ситуацию: компания начинает продажи на маркетплейсах. Ежедневно поступают десятки заказов (например, 50 штук), которые склад должен собрать и передать курьеру. В базе 1С 7.7 эти товары обычно объединяются в один документ отгрузки. Однако при получении отчета о реализации от маркетплейса через 2 недели возникает необходимость сопоставить каждую проданную позицию с конкретным заказом для контроля цен и возвратов. Проанализируем два основных пути реализации этой задачи.

Вариант 1: Добавление реквизита в табличную часть документа

Этот вариант кажется наиболее простым и логичным для тех, кто хочет сохранить привычный бизнес-процесс «один день — одна накладная». Рассмотрим, как это реализовать технически. Нам потребуется добавить новый реквизит в табличную часть документов Счет (Резерв) и РасходнаяНакладная.

Преимущества этого подхода:

• Минимальные изменения в логике проведения документов.
• Удобство для склада: все заказы за день видны в одном списке.
• Легкость визуального контроля при подборе товара.

Технические риски в 1С 7.7:

Важно помнить, что в версии 7.7 добавление реквизита в табличную часть (ТЧ) документов, которых в базе накоплены десятки тысяч, приведет к длительной реструктуризации таблиц DT*. Если вы используете DBF-версию базы, существует риск достижения лимита размера файла (2 Гб). Кроме того, штатно 1С 7.7 не умеет индексировать реквизиты табличных частей. Это означает, что поиск конкретного номера заказа в будущем будет выполняться медленным полным перебором строк.

Пример программного заполнения такого реквизита при загрузке данных из API или Excel:

// Пример добавления строки в документ с номером заказа
Док.НоваяСтрока();
Док.Товар = ВыбранныйТовар;
Док.Количество = 1;
Док.Цена = ЦенаМП;
Док.НомерЗаказаМП = НомерИзФайла; // Наш новый реквизит ТЧ
Док.ТекстСтикера = ТекстШК;

Вариант 2: Создание отдельных документов на каждый заказ

Многие специалисты по автоматизации рекомендуют придерживаться схемы «Один заказ маркетплейса — один документ 1С». Это может быть типовой ЗаказПокупателя или специально созданный новый вид документа.

Почему это может быть эффективнее:

1. Прозрачность расчетов: Легко отслеживать взаиморасчеты с маркетплейсом в разрезе каждого заказа (сделки).
2. Статусы: Каждому документу можно присвоить статус (Собран, Отгружен, Доставлен, Возврат).
3. Скорость поиска: Номер заказа можно вынести в шапку документа и сделать его индексированным. Поиск по такому полю будет мгновенным.
4. Аналитика времени: Вы сможете собирать статистику: когда поступил заказ, как долго он собирался и когда был фактически отгружен.

Рассмотрим ситуацию с объединением таких документов для склада. Чтобы склад не запутался в 50 отдельных накладных, мы можем создать обработку «Печать сводной заявки», которая соберет товары из всех документов за текущий день в один печатный лист для отборщика.

Проблема корректировки цен и отчетности

Выясним причину, по которой автору темы потребовался номер заказа. Зачастую Wildberries или Ozon присылают финансовые отчеты, где цена реализации отличается от той, по которой товар передавался на комиссию. Если мы храним номер заказа в строке накладной, нам будет проще реализовать обработку загрузки отчета комиссионера.

Проанализируем алгоритм работы такой обработки:

• Читаем строку файла отчета (содержит ID заказа и цену продажи).
• Ищем в базе документ РасходнаяНакладная, содержащий в строках этот ID.
• Если нашли — фиксируем разницу в документе ОтчетКомиссионера.

Для ускорения поиска в 1С 7.7 (если вы не используете прямые SQL-запросы через 1cpp.dll), рекомендуется ограничить период поиска документов датой отгрузки (например, за последние 30 дней), чтобы не перебирать всю базу за 5 лет.

Использование внешних справочников как компромисс

Если вы опасаетесь изменять структуру тяжелых документов, рассмотрим «гибридный» вариант. Мы можем создать справочник СвязиЗаказов, в котором будут поля:

• Владелец (ссылка на документ отгрузки).
• НомерСтроки (число).
• ИдентификаторЗаказаМП (строка).
• ШтрихкодСтикера (строка).

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

Выводы и рекомендации

Посмотрим на итоговый выбор автора: в условиях 1С 7.7 для упрощения текущей работы было решено добавить реквизит в табличную часть. Это допустимо при соблюдении следующих условий:

1. База работает на SQL-версии: В этом случае реструктуризация пройдет быстрее и безопаснее.
2. Объем документов в месяц умеренный: Если количество строк в месяц не превышает нескольких десятков тысяч, производительность поиска не упадет критично.
3. Необходимость печати стикеров: Номер заказа и данные для стикера жестко привязаны к позиции номенклатуры, поэтому в одной накладной не следует «сворачивать» одинаковые товары в одну строку (если у них разные номера заказов). Каждая единица товара — отдельная строка.

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