Проверка параметров и геометрии

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

Обычные спецификации

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

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

• Номенклатуре ошибки, рекомендуется назначать Вид номенклатуры - Техоперация, чтобы ошибки не оставляли следов в регистрах склада и потребности
• Номенклатура ошибки может иметь текстовую или графическую визуализацию - в этом случае, геометрический движок, покажет ошибку на эскизе
• Номенклатуре ошибки, рекомендуется назначать Тип элемента - Ошибка инфо или Ошибка критическая - это позволит гибко обработать разные классы ошибок
• Благодаря вычисляемым параметрам, условие контроля ошибки, может быть сколь угодно сложным и зависеть от контекста. Например, одним пользователям можно разрешить навешивать две створки с разных сторон на один импост, а другим - запретить. Пример, возможно, не самый удачный (створки не откроются), но он подтверждает универсальность и высокую гибкость методики
• Проверки можно размещать не только в технологических справочниках самого изделия, но и во внешних вставках, добавляемых к изделию автоматически через справочник Привязки вставок
• Проверки можно добавлять в параметрические вставки, которые рассчитывают спецификации монтажей и аксессуаров. В этом случае, не будет нарисована визуализация (у параметрических изделий нет эскиза) и в формулах вычисляемых параметров не будет графического контекста
• Не рекомендуется создавать сотни номенклатур ошибок, помним, что для целей аналитики, в строке есть ссылка на origin - родительский технологический справочник. Индивидуальный текст ошибки, можно формировать, как произведение номенклатуры на origin

Итак, если нужно проверить соответствие геометрии или параметров изделия неким требованиями, вы можете более не беспокоить разработчика. Хотите контролировать кривизну или толщину воздушного слоя в заполнениях - пожалуйста

События заказа

Не все проверки можно выполнить в момент расчета спецификации изделий. Например, контроль скидок или заполненность реквизитов заказа, удобнее выполнять в обработчике события before_save() документа doc.calc_order. Пример формулы-модификатора:

if ( typeof window !== 'undefined' ) {
const {prototype} = $p.DocCalc_order;
const {before_save} = prototype;
prototype.before_save = function() {
  if ( before_save.call( this ) === false ) {
    return false;
  };
  const {
    obj_delivery_states: {Отклонен, Шаблон, Подтвержден, Отправлен},
    elm_types: {ОшибкаКритическая, ОшибкаИнфо},
  } = $p.enm;
  const {errors} = this._data;
  if(errors.has(ОшибкаКритическая) && this.obj_delivery_state === Отправлен ) {
    // сюда врезать детальный показ ошибок
		
    // заглушка информирования об ошибках
    $p.msg.show_msg && $p.msg.show_msg({
      type: 'alert-warning',
      text: 'Критические ошибки в изделиях заказа',
      title: this.presentation
    });
    return false;
  }
  // если нет критических шибок, выполним дополнительные проверки
  if(this.obj_delivery_state === Отправлен) {
	
  }
};
}

Если обработчик before_save() вернёт false или Promise c false, процедура записи будет прервана, изменения на сервер не отправятся.

Добавить заказу индивидуальной бизнес-логики, можно подписавшись на события документа и рисовалки:

UPDATE и ROWS

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

// помещает в поле комментария предыдущее значение изменённого реквизита
typeof window !== 'undefined' && $p.doc.calc_order.on('update', (obj, fields) => {
  // если изменили комментарий - ничего не делаем
  if(obj instanceof $p.DocCalc_orderProductionRow && Object.keys(fields).indexOf('note') === -1){
    obj.note = JSON.stringify(fields);
  }	
});

Попробуйте подключить эту формулу и отредактировать в строке заказа количество или сумму - в поле комментарий увидите предыдущее значение изменённого поля