Объясните, почему для Approve Journal нельзя редактировать поле SumBy

[rusalaudinov]

В работе над проектом мне как-то задали вопрос.
В общем есть форма PurchEditLines с которой многие неоднократно сталкивались. На вкладке "Others" этой формы есть поле "Summary update for", которая обычно доступна, но если вызывать эту форму из invoice pool нажатием кнопочки Purchase order, то это поле будет недоступно, вот так:

Разобрался по коду, стало понятно, что всему виной строка кода вот такая

purchParmUpdate_ds.object(fieldNum(PurchParmUpdate, sumBy)).allowEdit(purchEditLinesForm.sumByAllowEdit());

она находится в методе run нашей формы PurchEditLines, соответственно возвращает false в случае если documentStatus у нас равен Approval Journal.

Так вот по коду вроде все понятно, а весь вопрос вот в чем. почему это поле недоступно при таких условиях? Логически. а то я во всей этой торговле не оч. понимаю.

[rusalaudinov]

Что вообще это поле делает и за что оно отвечает?

[Владимир Максимов]

Изначально, sumBy предназначена для возможной групповой обработки. В том смысле, что несколько исходных документов (в данном случае закупок) формируют один общий выходной документ - счет-фактуру или накладную.

Это имеет смысл, если форма вызывается из списка этих самых исходных документов. Но если Вы вызываете форму из списка уже готовых выходных документов, то какой физический смысл в групповой обработке? Что с чем предполагается объединять?

[rusalaudinov]

так, ну это вроде именно то что нужно. спасибо.

[glibs]

Если при разноске журнала регистрации накладных указать конкретную закупку, то поле Суммарная обработка инициализируется в "Нет". Если закупку не указать, или указать несколько закупок, то Суммарная обработка принимает значение "Заказ", и вы имеете возможность указать закупку, из которой слямзятся реквизиты "накладной" (инвойса).

Суть в том, что вы сначала регистрируете счет поставщика (инвойс), а потом связываете его с закупкой. Причем вы можете связать его как с закупкой один-в-один, так и с частью закупки или наоборот с несколькими закупками. Последний вариант, собственно, и называется суммарной обработкой (одна "накладная" по нескольким закупкам).

Для связывания зарегистрированной "накладной" с несколькими закупками вариант, отличный от одной "накладной" на несколько закупок невозможен, так как "накладная" уже есть и она одна.

Регистрация "накладной" очень удобна для реализации функциональности товаров в пути, когда количественный учет товаров до их оприходования на складе вести невозможно (до момента получения товара неизвестны пересортицы, излишки и недостачи). В таком случае сначала регистрируется инвойс поставщика, а потом при обработке "накладной" по закупке "накладная" как-бы не создается, а происходит связывание с уже ранее разнесенной "накладной".