УПД для Ozon в Диадоке: где проверить номер заявки и ID товара из 1С
Плагин Диадока для Ozon заполняет номер заявки и ID товара из данных 1С. Проверяем источник каждого поля и готовый документ до отправки контрагенту.
Содержание статьи
Плагин Диадока для Ozon заполняет номер заявки и ID товара из данных 1С. Проверяем источник каждого поля и готовый документ до отправки контрагенту.
Какие данные переносит плагин
Официальная инструкция Контур.Диадока описывает плагин, добавляющий номер заявки в заголовок документа и ID товара в строки. Значения можно получать из дополнительных реквизитов либо через выражение по данным базы. Само включение плагина не подтверждает правильность полей: их содержание зависит от выбранного источника в конкретной конфигурации 1С.
До настройки подготовьте контрольный документ с небольшим числом знакомых позиций. Для каждой укажите ожидаемые значения отдельно от результата выгрузки. Если проверять только наличие непустых полей, можно пропустить ошибку, при которой одинаковый идентификатор попал во все строки. Проверка должна отвечать на вопрос, соответствует ли значение конкретной заявке и конкретному товару.
Где искать номер заявки
В инструкции отдельно отмечено: дополнительный реквизит номера заявки относится к документу реализации, а не к счёту-фактуре. Поэтому сначала выясните, в каком объекте вашей базы фактически хранится нужная информация. Поле с похожим названием в другом документе не становится автоматически подходящим источником для плагина.
Практический порядок такой: откройте исходную реализацию, найдите заполненный реквизит, сопоставьте его с заявкой и только затем формируйте электронный документ. Если значение менялось, убедитесь, что создаваемая версия использует актуальные данные. Не подменяйте номер заявки номером внутреннего заказа лишь потому, что менеджеру так удобнее искать отгрузку: это разные системы идентификации, совпадение между ними нужно подтвердить.
Почему ID товара требует проверки номенклатуры
Для ID товара инструкция использует дополнительный реквизит номенклатуры. Такой способ не позволяет задать разные значения одной позиции с разными характеристиками. Если ваша база описывает размеры или цвета характеристиками одной номенклатуры, заранее проверьте, хватает ли выбранной модели данных для требуемого сопоставления с Ozon.
Составьте таблицу из трёх колонок: номенклатура и характеристика в 1С, ожидаемый ID, значение после формирования документа. Включите в проверку не только простую позицию, но и товар с вариантами. Если возникает неоднозначность, передайте настройку специалисту по вашей конфигурации. Не заменяйте идентификаторы массово и не применяйте непроверенное выражение к рабочим документам: ошибка может затронуть сразу весь ассортимент.
Проверяйте итоговый документ, а не только настройки
После настройки проверьте XML и печатное представление сформированного документа. Контролируйте число строк, связь каждой строки с товаром и значение заголовка. Повторите проверку после изменения реквизитов или конфигурации. Готовность бумажной формы сама по себе не подтверждает, что все необходимые электронные значения записаны именно в те поля, которые ожидает принимающая сторона.
Этот контроль отличается от физической маркировки груза. Для неё существует отдельный разбор финальных этикеток Ozon FBO в oShip. При сверке результата приёмки полезно также различать даты и состояния операций, как в материале про сопоставление статусов и дат Ozon. Завершённой настройку можно считать после проверки конкретного документа с известными исходными значениями, а не после сохранения формы плагина.
Материал отражает сведения на указанную дату. Правила и условия работы площадок могут измениться. Редакционные принципы