v7: Можно ли обработать двойной клик по таблице значений документа?

Процедуру повесить в свойствах таблицы значений : Дополнительно формула туда вписываете название своей процедуры отлика на событие

(2) тогда смотрите предопределенные процедуры что-то типа "ПриВводеНовойСтроки()" 2ой клик подразумевает это событие ?

+(3) у каждой колонки в свойствах есть свойства : дополнительно->формула

ПриНачалеРедактированияСтроки()

(7) изменяй в карточке товара

(7) "если пользователь видит, что этот реквизит пустой."

- документ от этого не изменится. как и результат его записи/проведения. нехрен документ юзать как АРМ управления товарами.
.
если пустой реквизить не приводит к ступору - нахрена его заполнять? если заполнение требуется/рекомендуется - делать это надо при реадктировании карточки товара, а не документа.

и вообще предлагаемый в (7) подход нехороший, ибо не соотетсвует шттаному поведению при работе с документами. для отдельного АРМ это еще допустимо. для документа - лучше не надо. имхо.

(12) м.б. лучше обработку нарисовать с т.з. , туда грузить вначале из екселя, там же добивать необходимые реквизиты , а потом создавать накладную и номенклатуру ?

(11) Если документ открывается на чтение, никаких дабл кликов ты не отловишь.
То что ты хочешь имеет право на жизнь, но это не форма документа, а форма обработки в которую загружается документ, а не сам документ.
И лучше сразу делай на ТабличноПоле из 1С++, там возможностей на порядок больше, чем у убогой ТЗ или МСЧ.

(11) я понимаю. я говорю о том. что документ - это не АРМ товара.
и все что надо чтобы было в документе - должно вносится при оформлении документа, до его проведения/записи.

(13) именно! хотя бы потому, что в результате чтения данных из экселя может запросто выяснится, что документ не надо/не может быть оформлен ввиду недостаточности данных, например.

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

(18) >>бы глядя именно на её и вносить тотже штрихкод по двойному клику.
Не хотите сделать проще : штрих-код вносить в табличной части документа в колонку "штрих-код" , а при записи документа перезаписывайте уже в справочные данные номенклатура (если ТИС единицы , или куда-то там ) ...

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

(21) а просто 2ой клик по т.ч документа имеет разные неоднозначные варианты развития события и поэтому не понятно что надо делать (22) странно как-то , такая спешка при оприходовании товара , как потом продавать -то , пока все не разнесешь - не продашь ?

(24) в общем , нет двойного клика ;)
(25) тогда и модели и штрих-коды на хрена нужны, если в продаже не учитываются ? :)

(18) "Именно такой вариант  решения самый правильный."

неправильный. еще раз. не надо из документа делать АРМ номенклатуры.
обработка номенклатуры ее модификация - отдельно. манипуляции с документом - отдельно.
на крайняк сделай DGA? которая открывает из дока обработку, в ней - делай что надо.

(20) "Логику реализации бизнес-процесса выбирает пользователь, вряд ли программисту здесь правильно учить менеджера )." - в корне неверно. пользователь исзодит из своих частных интересов. а проработку бизнес-процессов должен делать бизнес-аналитик. Пользователь далек от СИСТЕМНОГО подхода.

(20) "Дело в том, что процедуру оприходования товара нужно сделать максимально быстро, чтобы товар быстрее попала на приход." - фигня. уверяю тебя от того что приход будет проведен на 20 минут позже не изменится ничего. а данные можно будет отработать сразу все и сразу правильно.
.
если БП построен так что задержка ввода прихода в 20 минут - критична для бизнеса НА ПОСТОЯННОЙ ОСНОВЕ - должны быть вообще принципиально другие подходы к загрузке и наполнению документов и справочников. а то ты ужа и ежа скрещиваешь.

(30) ну так БЛИН И СДЕЛАЙ АРМ, а не работай из дока. и вопросов тогда не будет.

(32) херовый из тебя БА ;-)
и не потому что выше обсуждено, а потому что играешь "вкороткую".
но это лично мое мнение, на истину не претендую.
.
но скажу чисто просто - глядя на твой скрин где документ виден - шапка документа - трэш и угар. совокупность костылей условно говоря.
.
подсказка: сделай подсветку текущей двойной строки - манагеры тебе сразу спасибо скажут

(34) похрен.
УЧЕТНЫЙ ПРИХОД товара в базе у тебя никак не связан с реальной обработкой прихода на складе.

УБРАТЬ (не принять товар, а убрать) приход из тамбура - упирается сугубо в возможности техники и человеческие ресурсы на складе. со скоростью ввода УЧЕТНЫХ данных по приходам в базу это вообще никак не связано

(37) если приемка "доверительная" - то да.

бред какой-то...
"ещё раз объясню:
поставщик скидывает на мыло ТТН, в которой 150 позиций. Манагер берёт этот файлик и приходует за 2 минуты!.
Всё - приход готов. И уже продаётся и приносит прибыль )" - и в чем проблема? для ЭТОГО то, что спрошено в (0) нахрен НЕ НУЖНО.
на первом быстром этапе - быстрый импорт всего что надо обработкой (сначала на морду в тз и реквизиты диалога, соответствующие (или позволяющие заполнить) реквизиты документа, создаваемого по кнопке в этом же диалоге "Ок" (например)... дабл-клики для начального уточнения на ТЗ в таком диалоге - стандартно по формуле ТЗ, остальное тоже штатно и как угодно реализуется вполпинка, закончили - сохранили документ в базе данных, тут же открыли этот только что созданный документ в режиме РЕДАКТИРОВАНИЯ (с модификацией доступности ревквизитов - если это нужно, с доп.настройками в параметре если и это нужно) - и ШТАТНО РЕДАКТИРУЕМ документ. который уже проведен и оприходовал то. что уже продается!.. единственно - перепровести день (период) из-за того, что (ЕСЛИ) расход "срочно оприходованного" будет сделан до того, как будет введена полная информация, и (sic!) при этом дополнительный ввод информации в документ изменит информацию по остаткам (суммовую - как я понимаю. да?), которую нужно по этим остаткам пере-рассчитывать при расходе и фиксировать в базе (и которая после "уточненного" проведения сделает движения расхода неправильными - его для исправления нужно пере-провести).
это все - БАЗОВЫЕ СТАНДАРТы, и зачем рассусоливать и придумывать самому себе все эти проблемы - непонятно.

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

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

(45) еще раз - не надо из ДОКУМЕНТА делать АРМ.
если у тебя документ выполняет функции АРМ - то и сделай отдельный АРМ. который прозрачно для манагера и пр. порождает и карточки номенклатуры и документы и редактирвоание/исправление того и другого.

(48) нормальная схема.

(49) еще раз - не надо из документа делать АРМ. в документе - инфа нужная для документа. в этом суть документа. остальное - это АРМ

(50) нормальная учетная схема. собственно к приемке товара складом отношения не имеет.

(52) ясен пень приходят из учетного контура. но эти ордера - это _складская_ работа, и не имеют отношения к той учетной схеме которая у тебя в (48) описана.

(45): по слогам попробуй, парень. там все буквально разжевано - как это возможно и как это правильно и какие последствия. то, что ты вместо того, чтобы это понять - и в результате получить то. ЧТО тебе НУЖНО - предпочитаешь выплясывать и рассказывать, КАК тебе это нужно реализовать, и плевать на то, что это с самого начала для РЕШЕНИЯ ЗАДАЧИ - не то. еще раз - последний! - по слогам:
1) в диалоге импортируешь данные из указанного файла (опционально - настраиваешь получение имени и пути файла из параметра при открытии), реализуешь быстрое уточнение данных
2) в этом же диалоге - сохранение всех импортированных и уточненных данных в документ прихода. все - можно продавать!.. тут же открываешь сохраненный документ на редактирование (а не на просмотр!) для штатного уточнения данных с штатным же сохранением изменений и перепроведением... и - опционально - закрываешь диалог чтобы не мешал.

(55) я вообще делаю чуть иначе.
Все новые товары, которые у меня импортируются из обмена - скидываются в отдельную папку типа "НОВИНКИ_20210110". ВСЁ! Далее работа с новыми документам менеджерами и логистом по товару идет В ЭТОЙ ПАПКЕ. Это очень удобно
1. документы вообще не имеют к этому отношения, отпадают пробемы открыти/редактирования и прочего с документом
2. для обработки новинок - как сказал Евгений уточнение характеристик товара не всегда нужно в момент проведения прихода и в общем случае от прихода до полного уточнения характеристик товара может вообще неделя пройти) - не надо ИСКАТЬ документы в которых Новинки
3. например мне, как БА и ответсвенному за складскую логистику (в т.ч. в  ее взаимосвязи и с учетным контуром) - достаточно открыть группу "НОВИНКИ_ххххх" чтобы понять - выполняются требуемые регламенты или логист/менеджер хреном груши околачивают безо всяких поисков документов и работы через них. И то что менеджер и документы закачивает и товары пополняет - хотя это и может быть но это все лавочный подход и не значит что все это должно делаться "в документе". завтра у ТС появится отдельный "логист" которому будет закрыт доступ к документам вообще - он что - хрен околачивать будет?. А от одного-двух кликов открыть спр.номенклатура, перейти в группу "НОВИНКИ_ячччч" и херачить по товару все что там надо - скорость не пострадает. а профитов - на порядок больше.

на сим - у меня все. начинается второй этап у меня - настройка и разработка WMS для очередного проекта, времени особого нет словоблудием заниматься... ;-)

Нарисуй обработку с ТЗ на форме. ТЗ заполняй из ТЧ документа. Меняй в ТЗ всё, что угодно. Записывай обратно в ТЧ документа. Всё.

(63) Какую "новую закладку"? Ты о чём вообще? Зачем вообще открывать документ? Открывай копию документа в обработке!

Ты открываешь документ "НА ЧТЕНИЕ" а "НЕ НА РЕДАКТИРОВАНИЕ"!!! РАЗНИЦУ НЕ УЛАВЛИВАЕМ?? ))

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

Форма.ТолькоПросмотр(0); // блин!

(68) Если ты хочешь редактировать документ, ОТКРЫВАЙ ЕГО В РЕЖИМЕ РЕДАКТИРОВАНИЯ. В чём проблемы-то?

(69): ты идиот?.. это РЕАЛИЗОВАНО В ДВИЖКЕ при редактировании документа в диалоге. ШТАТНО. пользоваться этим - И ТАК МОЖНО, НАХРЕНА ПРОСИТЬ КАК РЕАЛИЗОВАТЬ ТО ЧТО УЖЕ РЕАЛИЗОВАНО И ЧЕМ МОЖНО ПОЛЬЗОВАТЬСЯ с необходимыми уточнениями.

(72): а что именно тебе мешает при редактировании документа "щелкать по пустой ячейке и вводить текст"?.. оно же и так уже работает. еще раз. ты - идиот?

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

(76): будешь моей бабушкой или модератором - вэлкам, а до тех пор - смело суй свои указания обратно в свой многострадальный организм.

(79): так ответ на это уже до меня - в (5) - а ты продолжаешь тупить. т.е. ми вопросы относительно твоей когнитивной состоятельности - не теряют актуальности.. )) особенно учитывая тот факт, что документ можно открывать и в режиме записи тоже - и именно это я тебе разжевал (в части выборочного запрета на изменения). да. вопрос был все-таки уместен. ))

(81): алё, гараж. ответ в (5) и его разжевывание (для когнитивно альтернативных) - в (77).
lol

(83): для идиотов: открывать документ можно (и для решения задачи - нужно) открывать в режиме редактирования. при этом для не-идиотов не представляет особой трудности программная оганичение доступности всего. что не должно быть недоступно (ну например всего кроме текстовой колонки, упоминаемой в (77), которое все тем же идиотам строго рекомендуется ппрочитать по слогам).
в общем и целом тебе уже дохрена раз рассказали, как можно решить твою задачу, но в связи с непонятночем (хотя предположения есть) это тебе непонятно.
ветра в спину. и мои соболезнования твоим клиентам.

(0) Можно, чего нет-то.

можно отловить нажатие и под нужную ячейку подсовывать текстовый контрол для редактирования с теми же размерами, аналогично тому, как реализовано редактирование в классе - редакторе ТЗ на форме.

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

(89) если ты ловишь тем же формексом, то плевать на права :)

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

(92) дык при нажатииКнопкиМыши..смотри события у объекта РасширениеФормы.
А там, получай ячейку по координатам, поверх двигай текст туда , в тексте событие и усё.

(93) или делать как в типовых - из журнала кнопка править реквизиты и открывается форма обработки, которая эммулирует сам документ и в которй можно править только "разрешенные" атрибуты.

или открывать не обработку, а копию дока через Открытие формы нового дока с копированием всех атрибутов из ссылки и при записи такого дока - статусвозврата(0) и через Запись() править документ-"родитель" ..это метод с синьоры.

(97) конечно можно.
Для этого класс-перехватчик пишется и всё, и в нём что угодно.
А конфу можно и не править, турбомд при необходимости.
А реализацию класса, можно и в обработке сваять и подключать по кнопке

Вот пример:
http://catalog.mista.ru/public/20038/