Можно ли обработать двойной клик по таблице значений документа?
7.7
Может различные формексы 1с++ ?

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

Не совсем верно выразился: табличная часть документа, у неё нет свойств для формулы

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

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

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

Открываю документ в режиме чтения. И хочется по двойному клику по определённой ячейке запускать разные процедуры

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

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

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

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

(10) не совсем понимаете идею. У товара разные характеристики есть. Например модель. Можно конечно нажать 5 кнопок чтобы отредактировать ее. Но намного быстрее двойной клик по столбцу Модель и сразу ее ввести.
Проведение документа тут ни причем. Он для чтения открывается

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

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

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

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

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

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

(13) Так и сделано )
https://prnt.sc/wkamry
из екселя грузится в ТЗ. потом обрабатывается и уже получаем табличную часть документа. которая в таком виде:
https://prnt.sc/wkane0
и меня, и моих пользователей меня она вполне устраивает, и хотелось бы глядя именно на её и вносить тотже штрихкод по двойному клику.
И не вижу здесь каких то извращений )
Именно такой вариант  решения самый правильный.

Другой вопрос что 1с это не позволяет Вот именно это я и хотел выяснить, можно ли обработать двойной клик по многострочной части.
Раз нет, придётся делать через ТЗ, что ЕСТЕСТВЕННО будет менее удобно пользователю

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

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

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

(19) Все эти штрихкоды и модели можно было бы и в екселе изначально вносить. Тоже не проблема.
Но всё это требует времени а оно не всего есть. Поэтому часто эту информацию вносят постфактум. Поэтому сейчас так: максимально быстро импортировать из екселя и поставить на приход. А уже потом вносить доп инфу (модели, штрихкоды и т.д.)

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

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

(21) "Откровенно говоря , не совсем я понял что надо вводить в накладную двойным кликом . если грузите из ексель , можно загружать в накладную и открывать форму документа для дальнейшего редактирования документа"
) ещё раз объясню:
поставщик скидывает на мыло ТТН, в которой 150 позиций. Манагер берёт этот файлик и приходует за 2 минуты!.
Всё - приход готов. И уже продаётся и приносит прибыль )
А уже потом в более спокойном режиме тратить 10-15 минут на ввод дополнителной информации, касаемой товаров. Эта доп инфа видна в многострочной части, и она там должна быть видна.
На любом нормальном языке когда юзер хочет изменить объект, он щёлкает по объекту, а не  создаёт отдельные ТЗ ))

(23) "такая спешка при оприходовании товара , как потом продавать -то , пока все не разнесешь - не продашь ?"
легко. Для продажи не нужны штрихкоды, не нужны связанные коды постащиков, и куча чего ещё не нужно для продажи. Для продажи нужен только сам товар и его цена, что и делается за 2 минуты

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

(26) Они нужны для других вещей. Например есть поле "модель онлайнера". Зная его 1с лезет на онлайнер.бай и парсит характеристики товара. и т.д.
Для продажи характеристики не важны сию секунду

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

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

(28) Правильно то, что даёт лучший эффект. Если манагер используя документ, который имеет АРМ номенклотуры, за месяц переваривать больше документов, чем используя другой вид документа - значит нужен первый вариант и именно он правильный.
Ответит на вопрос что эффективнее может только сам пользователь, попробовав оба вариант.
Я попробовал :)

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

(29) Будем считать что бизнесс-аналитик это я ))

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

(31) " фигня. уверяю тебя от того что приход будет проведен на 20 минут позже не изменится ничего. а данные можно будет отработать сразу все и сразу правильно."

Нельзя судить о бизнес процессах, не зная чтото о них.
Каких-то задач можно и месяц не касаться, а какието требуют реакции через минуту.

Если на склад приезжает машина каждые 10 минут, и товар в тамбуре склада не должен пересекаться с другими  приходами а из тамбура он должен уйти только после оприходования, значит приход должен быть сделан максимум за 10 минут. А лучше за 2 минуты, чтобы за оставшиеся 8 кладовщик его убрал из тамбура.
както так )

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

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

(36) в смысле не связан. он связан непосредственно

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

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

(38) ))
В 50% приходов кладовщик стучит манагеру и срочно требует проведения прихода.
Как можно судить у всех складах РФ и РБ не посидев внутри ? ))

(40) Потомучто у него на улице уже новая машина, а он ещё две предыдущие не разобрал. И если есть возможность товар оприходовать за 1ну минуту и дать фронт работы складу, значит нужно оприходовать за одну минуту.
А не создавать отдельную ТЗ и штрихкоды вбивать 20 минут \которые приемщику нафик не впали \\ ))

(35) "но скажу чисто просто - глядя на твой скрин где документ виден - шапка документа - трэш и угар. совокупность костылей условно говоря."

С удовольствием приму конкретную критику )

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

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

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

а кто говорит что для быстрого оприходования товара за одну минуту нужен двойной клик?
Не совсем понимаю - очень много текста, но суть не уловил.
Ещё раз то что есть у меня:
1. Создал новый документ.
2. Нажал на кнопочку, 1с сама нашла и прописала в шапку путь к файлу прихода
3. Перешёл на закдадку ПриходЕксель, нажал кнопочку импорт, и весь товар попал сначала в ТЗ. глазами проверьь что всё ок и нажал вторую кнопучку Импорт.
4 Свежие товары (их обычно около 5-10%) руками разбросал по группамм в справочнике номенклатуры.
Всё. На всё это уходит обычно  1-5 м.

Что здесь не правильно?  
После этого кладовщик может принимать товар.

Далее такие данные номенаклатуры как "модель" "модельОнлайнера" "штрихкод" я хочу видеть всегда у каждого товара при открытии прихода. и контролировать это через открытие прихода.
НЕ НА ОТДЕЛЬНО ЗАКЛАДКЕ, КОТОРУЮ НУЖНО ОТКРЫВАТЬ а именно сразу в многострочной части.
Что здесь не правильно?

И когда я вижу что автоматический импорт гдето чтото сам не заполнил я хочу максимально быстро заполнить. Зачем это делать из ТЗ, если бы это можно было сделать сразу из многострочной части документа??

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

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

(44) На склад можно скидывать ЛЮБОЙ документ, в котором кладовщик должен расписаться. И как он будет называться, "ордер" или "приход" или "ТТН" - по барабану.
Фактически же кладовщик принимает товар по накладной, в РБ это бланк строгой отчётности. в котором и расписывается.
Вот эта ТТН и должна быть внесена в 1с.
Которую кладовщик должен увидеть, сверить с бланком и расписаться.
После того как кладовщик сверил бумажну ТТН с документом Прихода в базе, он ПЕРЕМЕЩАЕТ по межскладской товар со склада Транзит (на который товар падает по приходу) на свой склад

(47) "еще раз - не надо из ДОКУМЕНТА делать АРМ."
я не понимаю о чём речь.
Я не делаю из документа АРМ.
мой документ прихода выполняет свою конкретную роль - оприходовать товар на склад. Всё.

Далее в этом документе я хочу видеть ту инфу, которая мне полезна . И править эту инфу максимально эффективным способом

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

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

(46) "на склад - сброшены 10 ордеров - 10 машин прихода на утро. склад их принимает независимо от того что там в учетном контуре проведет менеджер"
_______________________________________________


эти Ордера в базе по мановению волшебной палочки появляются, или их создаёт менеджер ? ))) \\в своём учётном контуре\\

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

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

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

(55) а теперь расскажи как у меня это процесс реализован ))
Я так понимаю знаешь? )

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

(55) Момент номер раз: вполне возможно и правильно, что у манагера и не должно быть прав на редактирование прихода, когда в нём расписался кладовщик. Такая логика применима в 50% случаев и обычно в более продвинутых учётах.
Поэтому просто так раздавать советы по поводу изменения проведённых документов - я бы поостерёгся.

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

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

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

(58) "Отредактировать требуется не информацию, которая находится в документе, а характеристики номенклатуры /модели, штрихкоды/!"
- правильно! открой инструмент работы с номенклатурой. и делай там ;-)

(57) "Все новые товары, которые у меня импортируются из обмена - скидываются в отдельную папку типа "НОВИНКИ_20210110""
_________________
естественно. это стандартный механизм. Оттуда они расскидываются руками по нужным группам.
Но расскидывание номенклатуры по группам и вбивание характеристик товаров - немного разные вещи. Одно от другого не зависит.


"А от одного-двух кликов открыть спр.номенклатура, перейти в группу "НОВИНКИ_ячччч"
________________
нефига. Какраз таки переброс новых товаров из группы "Новинки" по нужным группам номенклатуры и производится на этапе первых 2-5 минут.
А вот этап штрихкодирования, определения моделей, парсинга характеристик - более длительный этап. И делать его логично какраз таки из документа , а не справочника номеклатура !!
В номеклатуре группа "новинки" всегда должна быть пустой  на начальном этапе проведения прихода!

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

(62) блин ))). да понято что можно так )))

Но неужели не понятно, что это не правильно??? )))
Правильно у Эпла - иметь одну кнопку на машке. Щёлкать еЙ по объекту и делать с объектом что хочешь.

И если юзер хочет в многострочной части документа видеть модель товара - это вполне нормальное желание. А если он его там видит, и хочет его тамже отредактировать - ЭТО ТОЖЕ ПРИАВЛЬНОЕ ЖЕЛАНИЕ. И МАКСИМЫЛНО ЭФФЕКТИВНОЕ.
а редактиривание модель через ТЗ - гемор.
Это сначала нужно открыть новую закладку , затем найти в неё нужный товар и только потом редактировать

РАЗНИЦУ НЕ УЛАВЛИВАЕМ?? ))

А мне тут блин доказывают, что я баран, и у меня не правильные желания. И что правильно модель товара править через ж.., на отдельной ТЗ.

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

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

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

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

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

(66) ну и пусть имеем ограниченный доступ. Это ещё более продвинутый уровень учёта. Только какое отношение это имеет к тому, что юзер хочет править объект щёлкая по этому объекту а не искать его в отдельно окне????

(67)
какое отношение это имеет к тому, что юзер хочет править объект щёлкая по этому объекту а не искать его в отдельном окне????

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

(71) Ёпп, мы читаем то что сверху ????
Мы вникаем в суть темы или лишь бы блабла??

Где была речь что мне нужно редактировать документ????

В очередной раз:
Есть документ. В документе есть Товар. У товара есть реквизит. Реквизит для наглядности показывается в многострочной части документа.
Если этот реквизит у каких то товар пустой, пользователь хочет иметь максимальной просто способ редактирования ЭТОГО РЕКВИЗИТА НОМЕНКЛАТУРЫ.
Самый просто способ это щёлкнуть по этому пустому полю и ввести значение !!!


Никак не открытие справочника номенклатуры, либо открытия этого документа в другом окне, либо заполнения гдето в другом месте отдельной ТЗ и правки данных там. НЕТТТ

САМЫЙ ПРОСТОЙ И УДОБЫНЙ СПСОБ- ЭТО ЩЁЛКНУТЬ ПО ПУСТОЙ ЯЧЕЙКЕ И ВВЕСТИ ТЕКСТ.

ЭТО НЕ ПОНЯТНО????


и в (0) я спросил о том, позволяет ли язык 1с 7.7 реализовать этот самый простой способ или нет. А ВМЕСТО ЭТОГО МНЕ ПЫТАЮТСЯ ДОКАЗАТЬ, ЧТО БЛИН ЭТОТ СПОСОБ ПРАВКИ ИНФОРМАЦИИ ГОЛИМЫЙ И ЧТО Я БАРАН.

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

(73) )))))))))
Ребята, расскажите Cthulhu, что он не догоняет. Видать мой текст он просто не читает )

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

(75)
И язык свой немного придержи.

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

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

(77) Да Блин что ты говоришь???
Уже прочитал что править нужно не документ??

Ещё немного времени потрать и выясни, что документы могут открываться не только в режиме ЗАПИСИ !

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

(60) "Отредактировать требуется не информацию, которая находится в документе, а характеристики номенклатуры /модели, штрихкоды/!"
__________________________________
- правильно! открой инструмент работы с номенклатурой. и делай там ;-)
__________________________________
во сколько раз быстрее это сделать из документа, нежели в справочнике номенклатуры ? )).
Повторюсь, изначально логист раскидывает новые товары по группам в дереве, а уже потом переходит к следующему этапу - редактирование реквизитов этих новых ТМЦ.
Искать эти товары  в справочнике и править реквизиты - точно не лучшая идея.

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

(82) Для слабовидящих:
https://prnt.sc/wkdbt1

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

(84) Как вам прпытки оправдания слепоты и слабоумия? ))

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

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

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

(87) Отловить ведь можно только если есть права на редактирование и можно открыть в режиме записи? А если прав нет?

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

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

(90) Так вот и не знаю как формексом ловить )

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

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

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

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

(96) Чуток не по теме.
А можно реализовать глобально обработку открытия документа?
Т.е. чтобы описать её один раз для всех документов и при открытии документа этот модуль выполнялся?

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

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

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

(97) http://catalog.mista.ru/1c/articles/73221/
вот здесь вроде как разжованный фак. но мне, только немного программеру, да ещё и штатному пока не дошло )

при запуске 1с такая ошибка:
ПерехватчикСобытийГМ = СоздатьОбъект("КлассПерехватСобытий");
{Глобальный модуль(2468)}: Неудачная попытка создания объекта (КлассПерехватСобытий)


возможно это не верно сделал?:

"После чего создаем обработку с именем «defcls», в теле которой пишем такой код:
//# класс КлассПерехватСобытий = КлассПерехватСобытий@MD
//# {};"

эту обработку сохранил в папку с конфигурацией.

пробовал в ней и убрать //
всё-равно ошибка при старте.

согласно инструкции по ссылке, в ГМ прописано:

ЗагрузитьВнешнююКомпоненту("1cpp.dll");
НастройкиВК = СоздатьОбъект("УправлениеНастройками");
НастройкиВК.Установить("ПерехватитьСобытияГК",1);
ПерехватчикСобытийГМ = СоздатьОбъект("КлассПерехватСобытий");
Перехватчик = СоздатьОбъект("Перехватчик");
Перехватчик.ПерехватитьСобытияГлобальногоМодуля(ПерехватчикСобытийГМ);    

две обработки Defcls.prm и КлассПерехватСобытий.ert
сохранены в папке конфигурации

Разобрался.
Обработку "КлассПерехватСобытий" нужно было в конфигурацию вставить а не внешней

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

(61) "А вот этап штрихкодирования, определения моделей, парсинга характеристик - более длительный этап. И делать его логично какраз таки из документа , а не справочника номеклатура !!"
- неверно.

(63) у тебя объект с которым ты РАБОТАЕШЬ (а не который открываешь) - это карточки номенклатуры. вот и работа й сними "из номенклатуры".

еще раз - у тебя концепция работы с _карточками номенклатуры_ из документа - ущербная. для пользователей, у которых будет закрыт доступ к документам, такой функционал работы с НОМЕНКЛАТУРОЙ будет недоступным (что есть бред). то есть работать надо по номенклатуре, но почему-то это недоступно...

(68) еще раз - в такой концепции сделай АРМ, который выглядит так как удобно и порождает нужные сущнсоти и действия сними

(81) "Искать эти товары  в справочнике и править реквизиты - точно не лучшая идея."
потому что концепция у ntz, тупая. новинка товара определяется "мгновенно" если сделано правильно, ее искать не надо. А если правка новинок сделана через документ - то "мне" - пользователю, который не являтся владельцем" документа - надо открывать документы - их еще найти надо. в открытых документах искать необработанные новинки среди обработанных итд. криво и тупо. ориентировано на пользователя который "я заню что вот полчаса назад я заводил прихолд и мне надо в нем зайти и поработать".

впрочем, никто не мешает делать как хочется. "Хочется" - это бооольшой двигатель.

(105) Ну какая разница что необходимо править, номенклатуру или поля документа.
Результатом это правки должны быть одно - заполненные реквизиты товаров.

А метод правки выбирается исключительно из его эффективности.

Если придумать метод, когда 100 новых товаров быстрее отредактировать через справочник чем через документ - не вопрос. Делается через справочник.
Но пока я не вижу как не написав несколько десятков строк кода легко реализовать более простой способ правки через справочник.
А вот через документ это намного быстрее и без лишнего кода в 10ок строк

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

Мне видится логичным правкой новой номенклатуры руководить из прихода. У нас несколько менеджеров могут "покупать" товар. И каждый обрабатывает только свои приходы: парсит фотки товаров, парсит характеристики и т.д.
Если делать это из справочника, тогда они не смогут работать только над своими приходами /либо опять же более геморойно это реализовать/

А так - каждый  видит свои приходы, и обрабатывает из них только "свои" товары

(108) А если правка новинок сделана через документ - то "мне" - пользователю, который не является владельцем" документа - надо открывать документы
__________________
элементарно: в Журнале прихода доки подсвечиваются, если товары в них не до конца заполнены:
https://prnt.sc/wkgaoj
мне достаточно одного цвета. Но можно конечно ввести много разных цветов.
Юзер может отфильтровать только свои приходы, и по цветам он видит те что не обработаны.

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

(107) " еще раз - в такой концепции сделай АРМ, который выглядит так как удобно и порождает нужные сущнсоти и действия сними"
________________
это не совсем  понимаю. Ну давай назовём то что я сделал АРМ. Что это поменяет? )

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

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

(115) "А я стремлюсь эти движения минимизировать" не, ты стремишься сделать ровно, как тебе приснилось. на голубом глазу игнорируя все советы

У меня принцип такой: если манагер купил товар - значит он покупку должен довести до конца. И цвет этого приходного документа должен быть черным а не красным. Вполне допускаю что во многих других компаниях разделение труда может быть иным

(116) совет я услышал только один - править номенклатуру из справочника, потому что так правильно ). Аргументация была так себе ))

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

За общение спасибо, всегда полезно слышать критику со стороны.

править справочник (устанавливать по списку значение реквизита) - "больше движений"??? чувак не в курсе режима редактирования справочника "в списке" / "в диалоге" / "обоими способами"??? и микроскопом хочет гвозди забивать (брат Ёпрст, может хватить над человеком издеваться-то lol)))

(115) АРМ - это не работа в справочнике. работа в справочнике - это работа со штатными механизмами.

(115) АРМ это и есть - создание удобного и непротиворечивого инструмента для быстрой/удобнйо работы. Не ломаю при этом типовые концепции и правила. А то что ты делаешь в документе "давай назовем этот документ АРМ" - это натягивание совы на глобус.

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

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

Сделать дополнительную форму списка справочника (9это штатно). вынести на форму в список все нужные для зщаполнения "несущественные" реквизиты. В любом месте - хоть на панелях, хоть в менюшках, хоть в документах/ВПФ хоть где сделать вызов это формы "одним кликом" с установкой отбора по признаку "товар = новинка". всё. преимущества - скорость не потеряна, а даже увеличена, видно сразу все неотработанное, а не раскиданное по документам которые помнить надо, задействованы только штатные механизмы. и прочее...
.
это вообще если не думать как сделать "АРМ". такая форма списка - и будет АРМ

(120) это без проблем. чем еще заняться как не попинать собрата по ремеслу;-)

Не открыаать документ для чтения уже предлпгади?

Или кнопку повесить на форму которая будет открыаать анплог ьаб чпсти

Та и ваще..если константа или чето там приоткрытии статусвозврата 0 открыть обработку

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

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

(128) Да предлагали. У многих юзеров нет прав на редактирование проведённых документов.
(130) Это легче и понятней чем двойной клик по объекту?
(129) Можно и кнопку, можно ещё кучу вещей придумать. На каждую операцию свою кнопку. Но вопрос был про двойной клик, который наиболее близок к сути редактирования объекта.

(131) "если у вас хозоперация - приход, без всяких штрихкодов, то ровно это и должен делать документ. в нем не должно быть этих штрихов и прочего."
_______________________________________
Скорее всего ваше предположение возникло изза того что не прочитали текст выше.
Естественно что модель товара , штрихкод товара и т.д. не ХРАНЯТСЯ В ДОКУМЕНТЕ.
Они просто выводятся там и это реквизиты товара. И раз они там выводятся, то логично дать способ в том числе и  оттуда их править. Нет ???
Логичней к той форме приходного документа, с которой логист постоянно работает и привык к ней платить программеру, чтобы он придумал ещё один способ правки информации, и в частности исправить модель товара, если мы видим в документе прихода, что она не введена??

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

(132)Если видим колонку в МЧ документа, значит это именно реквизит документа? )

(134) Не отовсюду, а из ОДНОГО места, откуда наиболее эффективно и правильно

(135) нет. но нахрен нам видеть в документе то, чего видеть не надо?

(136) вот у вас вся конфа и написана "через это место"

На американском форуме задаёшь вопрос, тебе дают ответ.
На израильском форуме задаёшь вопрос, тебе задают встречный вопрос.
На русском форуме задаёшь вопрос, а тебе долго и нудно рассказывают, какой ты мудак. (с)

(139) "здесь говорят правду!"©

(137) "видеть в документе то, чего видеть не надо?"
)))
Именно программер должен определять что должен видеть манагер у себя на столе, как раскладывать документы в стол и подписывать папки ?

(141) Да. Ибо менеджеры en masse туповаты и не умеют организовывать рабочее место

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

(143) опять: "нормальный подход" )
А чем КОНКРЕТНО другой подход не нормален?
Во всех мессагах ноль конкретики

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

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

(143) Конкретный вопросы:
- Это не правильно что модель товара видна в МЧ документа прихода? Её оттуда нужно убрать? От этого повысится производительность труда менеджера?
- Это не правильно, что если в МЧ документа юзер видит что модель товара не заполнена /не проимпортировалась из екселя автоматом/ иметь пользователю возможность быстро скопипастить модель ?

Всё эти желания - это желания через ж... ??
п.с. меня умиляет, когда люди не знают сути, не вникают в суть предмета, но так уверенно раздают советы

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

(146) "тем что имеющиеся механизмы не позволяют реализовать наиболее интуитивно понятное действие."
лично для меня - двойной клик по объекту для дальнейшего его редактирования - наиболее интуитивно понятное действие

(148) чем вам не нравится двойной клик??

(149) согласен. приначалередактированиястроки()

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

(152) в одной из контор где работал внедрили систему 5С.
это была боль.
но какое то подобие порядка все же наступило.
хотя год спустя все вернулось почти к тому же что и было.

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

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

(142) а когда туповатые менеджеры работают под туповатым менеджером высшего звена...
(146) если кто-то когда-то решится переносить _это_ накудато - он не "огребет проблем", а умрет со смеху...

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

(154) Его не нужно искать
Он создаётся изначально с нуля и менедждер с ним работает. И из него выполняет всё что нужно сделать по приходу. В том числе и заполнить модели товаров.
Все приходы в одном журнале приходов.
Не обработанные до конца красным цветом.
В чём проблема найти???

(154) "Менеджеру придется зайтив два документа как минимум и то при условии что он помнит/знает в какие документы заходить"
Ерунда. ему ничего не нужно помнить.  Ему нужно только не быть дальтоником

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

(154)
"если учесть что правкой номенклатуры может заниматься другой менеджер чем тот кто грузил документ (ну заболел он внезапно) то выделение такой номенклатуры для доработки новым менеджером превращается в захватывающий квест лазания и поиска по документам."
_________________
в моих бизнес-процессах перчивен не справочник номенклатуры, а первична Закупка товара.
Менеджер купил доим, и работает над этим домом. Дом=проект=документ прихода. В доме куча материалов, которые нужно обработать. Эти материалы пересекаются с другими материалами других домов.
Но манагер купивший дом, работает с домом !

Такая бизнес-модель не имеет право на жизнь??

я должен это всё объяснять программеру когда спрашиваю у него как обработать двойной клик по элементу при открыти документа толкьо для чтения? ))

(160) "пичалька только в том, что я думал что ты более квалифицирован в постановке бизнес-процессов.."
______________
это всё ярлыки.

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

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

(161) пля... ну вот и нужно обрабатывать не дом, а материалы. О чем тебе и говорят.

(163) Блин, да потомучто ЭТО МЕНЕЕ УДОБНО!!!
Сколько ещё раз объяснять???
Удобней и правильней щёлкнуть по пустому место и скопипастить туда инфу !!!

НЕТ ???? Нужно для этого отдельную ТЗ создавать ???

(166) а нахрена ты создаешь отдельный документ на каждый приход?  
удобней же общую таблицу. и копипастишь номер, дату, клиеннта, номенклатуру...

(167) Вот это именно и есть ваш подход )))
Нахрена делить, когда можно номенклатуру править в справочнике номенклатуры )).

(168) "— И где же я должен принимать пищу?
— В спальне!
— Очень возможно, что Айседора Дункан так и делает. Может быть, она в кабинете обедает, а в ванной режет кроликов. Может быть. Но я — не Айседора Дункан. Я буду обедать в столовой, а оперировать в операционной! Передайте это общему собранию."©

(167) Тебе вредно читать фузиновские ветки, ты у них идеи крадёшь ))

Ладно, всё понятно. Здесь все Кашпировские и лечат по телевизору. Даже не взглянув на пациента. Гуру бизнеса.

(171) просто многие из нас видели более чем одну учетную систему.

(170) почти не читал. что, у них одна таблица?

(173) Да что-то такое промелькивало... Хотя я могу ошибаться

(174)
дежа вю.  
еще бы предложили реквизит с настраиваемым типом...

(174) Ошибаешься

(171) Все же просто. Если форма открыта в режиме "Только просмотр", то и доступа к редактированию нет. Но ничего вам не мешает сделать на этой форме отдельную кнопочку. По нажатию откроется форма обработки, в которую передаешь данный документ "Параметром". А уже в той обработке заполняешь что угодно и как угодно, а также даешь пользователям удобные инструменты для заполнения, редактирования и прочего. Например, если все нужные поля заполнены, то такие товары в этой обработке сразу не показываешь, чтобы Пользователь не лазил по большому документу ради одной позиции. Ну и т.д.

(176) это, суко, неудобно! у ТС 100500 документов в день менеджер обрабатывает. 100500 лишних кликов на кнопочку. кнуп = 1 сек, 100500 сек, это же целый рабочий день! не успеет!

(176) ему нужны заполненые товары, чтоб копипастить оттуда... :-)
просто он забывает, что автоматизация бардака приводит к автоматизированному бардаку.
лучшая иллюстрация - его же скрин в (112), колонка "контрагент".

(177) дык я не понял, разве формексовская ПриДвойномНажатииЛевойКнопки() не отрабатывает в ТолькоПросмотр?

(177) ускорять можно и нужно. я бы в некоторых случаях и драг-н-дроп применил, если это логично и обосновано. но начинать-то надо не с автоматизации бардака, а с ликвидации бардака.

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

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

(176) Ну конечно, на три реквизита три кнопочки. В чём проблема )

(177) Ну конечно удобней это делать через кнопки
(178) какая проблема  с колонкой Контрагент?
(180) Из 183 трёх месаг хотябы одна конкретная будет?

(181) https://prnt.sc/wkw9zn
модели можно и в ТЗ заполнять, только уже писал 100 раз - на это нужно на одна минута, а часто минут 10-20. потмоучто помимо моделей ещё куча другой инфы есть для окончательного оприходования.
И не всегда всё делается до конца.
И тогда такие приходы подсвечены красным.
И манагер видит свои красные приходы в журнале, /И БЛИН НЕ НУЖНО ПОЛДНЯ ИХ ИСКАТЬ В ЖУРАНЕ - ХИ ПОДСВЕТИТЬ МОЖНО/
спокойно открывает, СРАЗУ видИт многострочнуЮ часть и спокойно исправляет через двОйной клик .

И ИМЕННО ТАК ПРИАВЛЬНО,  а не  вешать для этого кнопки или мудрить отдельную обработку.

А СЕЙЧАС ПОЛУЧАЕТСЯ ЧТО МНЕ ГОВОРЯТ: ТЫ ПЛОМБИР ТЫ НЕ ПОКУПАЙ, ЛУЧШЕ КУПИ ШОКОЛАД, ОН ЖЕ ВКУСНЕЕ НАМНОГО.
Я спрашиваю, а почему? Ответ - А ПОТОМУЧТО ЭТО ВСЕ ЗНАЮТ, У НАС ОПЫТА БОЛЬШЕ

(182) Очень сложно по 100 раз объяснять каждому, что  у меня есть отдельная закладка ТЗ, в которой принимается xls файл и обрабатывается. И если там не заполнена модель /или другие нужные реквизиты/
то манагер это заполняет в ЕКСЕЛЕ перед нажатиме кнопки Импорт. Но если он по своим соображениям не всё заполнил, то я хочу иметь максимально быстрый способ заполнения, открывая подсвеченный красным документ прихода.

НО ОКАЗЫВАЕТСЯ ЭТО НЕ ПРАВИЛЬНО )

(183) ну а в чем проблема сделать через кнопку, если ты не можешь по другому? я вот специально скачал и поставил платформу, и проверил в режиме Просмотр - у меня прекрасно отрабатывает даблклик :-)
(185) небе говорят: "не  все то, что коричневое - шоколад"

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

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

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

(187) А я поленился проверять, поверил ТС на слово )))

(184) проблем простая - у тебя ТУПЫЕ менеджеры не могут однообразно заполнить реквизиты контрагента: где-то имя-фамилия, где-то фамилия-имя, где-то имя-телефон, где-то телефон-имя.

(187) В режиме просмотр штатными средствами двойной клик НЕ обрабатывается штатными средствами. По крайней мере никто не написал как это сделать. /Если док открывать для записи тогда легко/
День назад я этого не знал, поэтому и завёл тему.
завёл тему потомучто:
1) потомучто я хочу через двойной клик и мне нравится пломбир а не шоколад
2) узнать, впринципе ли возможно обработать двойной клик в МЧ документов 1с при открытии дока для чтения

(189) не, ебстебственно, формексом, а не просто даблкликом. но, млин, можно было уже за сутки взять и проверить.

(191) в клюшках можно сделать фактически что угодно

(188) Есть специальная обрабоки, которые по номеру телефона /или любому другому тексту\ через прямой запрос за ОДНУ секунду находят нужного контрагента.
как так ?? Кашпировские ведь должны всё знать

(194) еще раз, для особо одаренных: нужно не автоматизировать бардак, а не допускать оного

(189) Более менее конструктивно )
Отвечаю. Если я решил, что хочу видеть в МЧ прихода три реквизита товара, и решил иметь возможность их править из этого документа, то проще их править через двойно клик.
И это кстати я уже реализовал. Повысил права юзеров на документа и открываю их в режиме записи.
Изначально я не знал такого решения

(195) Обобщаем дальше

(197) можно и обобщить: по закону соответствия менеджеры соотвествуют руководителю, а руководитель в менеджерам.

(198) Главное что  Mikeware всё знает )

(199) Чего ты завелся?
Это семерка писалась для пользователя (и было это давно и неправда), а в восьмерке - программе виднее, как надо.

(199) Хуже, что ты этого не можешь понять

(200) у него рукопись. нетленка

(202) И что?

(200) Ни одного конретного утверждения. Только:
(190) " у тебя ТУПЫЕ менеджеры"
(201) "ты этого не можешь понять"
(195) "нужно не автоматизировать бардак, а не допускать оного"

и так во всех сообщениях. Конструктивно умеем общаться?

(204) то, что Вы хотите одно из единственных конкурентных преимуществ lsFusion

(205) Я хотел только двойной клик по ячейке )

Но не исключаю что могу изза этого клика не только платформу поменять ).

(203) то, что конкретно эта "семерка" писалась не для пользователя...
(205) редактировать реквизиты элемента справочника в списке, в котором есть сразу элемент справочника?
не, это легко, но нахрена?

(207) "наш изя сменил таки пол!"©

(208) Потомучто:
1) это быстрее чем открыть элемент в справочнике
2) не нужно давать права на изменение элемента справочника /если не мудрить реализацию прав/

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

(185) нихрена не так. ты работаешь исключительно по оптимистическому сценарию. это прямой путь к траблам. самый простой вариант: журнал открыт с таким периодом, в который не попадает неотработанный "документ" (ну вот получилось так). Или формекс гряпнулся. Или еще что. И жопа. Неотработанные номенклатуры "потерялись", потому что у менеджера всегда жопа в мыле. Должен быть единый ЦУП/АРМ для работы с "проблемной номенклатурой", не привязанный непосредственно к открытию документа. в этом цупе/арме - тащитяс все проблемное по текущему менеджеру/юзеру (обрабатывая унутре все неотработанные документы и прочая). в таком арме 1. он может быть реализован отддельнйо обработкой, и не надо каждый раз при исправлении логики "арм" обновлять конфигу 2. можно сделать всякого полезного больше чем в документе, хотя бы тупо тем что в таком арме он не будет "засоряться" уже отработанными позициями. ну и проч...

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

(212) Может быть куча разных механизмов. Это не исключает того, что если менеджер видит гдето проблему, он должен иметь способ её сразу быстро исправить

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

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

"Неотработанные номенклатуры "потерялись", потому что у менеджера всегда жопа в мыле. Должен быть единый ЦУП/АРМ для работы с "проблемной номенклатурой", не привязанный непосредственно к открытию документа."
_______
Ты уверен что такого Арма нет?
Наличие такого Арма исключает возможность редактирования данных по двойному клику?

(215) ""если не мудрить реализацию прав" - и потом хрен отследишь, кто что менял.  и не разграничишь права, не обеспечишь целостность данных, и много-много других моментов."
__________________
Речь была об изменение элемента справочника а не документа.

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

(216) наличие АРМа не исключает возможность редактирования, но делает его менее нужным
(217) и я об изменении "элемента справочника".

(216) "Наличие такого Арма исключает возможность редактирования данных по двойному клику?"
нет, не исключает. но залог устойчивой работы, прогнозируемой, плановой и легко контролируемой извне (в том числе ЧТО ТЯЖЕЛЕЕ ВСЕГО - контроль менеджером самого себя) - отсутствие альтернатив. Особенно при массовой потоковой работе, каковая есть у тебя.

(217) "Речь была об изменение элемента справочника а не документа."
менять элементы справочника заходя через документ в справочник - рвать гланды через жопу.

(220) это пол-беды. беда в том, что для этого разрешается редактирование документа. что дает простор для сам знаешь чего....
Впрочем, "не в кобылу овёс..."®

(221) И откуда такой вывод что разрешается редактирование документа?
Опять Кашпировский? )

(220) "менять элементы справочника заходя через документ в справочник - рвать гланды через жопу."

Это ярлык. Мне кажется правильней либо конкретно говорить почему шолоколад лучше пломбира, либо не говорить вообще.
Т.е. если юзер отредактировал поле элемента  через справочник /как здесь делают 100%/ это нормально. А если иметь возможность отредактировать это поле из документа - всё, конец света

(216) Дался тебе этот двойной клик в документе, открытом для просмотра!
Если эта процедура с вводом недостающих реквизитов массовая, то это надо делать в другом интерфейсе на этапе загрузки.
А если редкая, повесь на кнопку.
И тот и другой вариант тебе уже разжевали.

(94) Ёпрст, где посмотреть как получить ячейку по координатам даблклика? Помнится, где-то обсуждалось...
(163) Больше закладок богу закладок!
(185) Ёшь твою еть! По скрину понятна глубина ... эм... глубины.

Насчёт разжёвывания и упорства: просто ТС акцентуированный эпилептоид. Без обид, это не обзывательство, а констатация типа характера. У такого типа есть весьма полезные положительные качества. Но не в нашем случае. ТС построил свой велосипед, хочет чтоб вот тут блестело, а ему говорят, дескать конструкция неоптимальная и вообще... Не прокатит. Он строил, строил, а Вы все как сговорились! "Зачем тебе чтобы блестело? Лучше цепь смажь и лишние колёса открути!" ;) Не в коня корм.

(0) По существу: - На мой взгляд надо смотреть в сторону формекса в (94). Получится именно как ты хочешь. И усугублять нах...раписто.

(222) так один чувак в (196) напейсал: "Повысил права юзеров на документа и открываю их в режиме записи." Не знаешь того чувака?
(223) естественно, это ярлык. Если чуваку десять раз объяснили, что в жопе нет шоколада, а он требует доказать, что изжопный шоколад вкуснее - на него клеят ярлык "идиот"

(224) Я повесил это на двойной клик, это намного разумнее чем забивать окно документа кнопками. И мне не понятно как с этим можно спорить

(225) йо. как то я упустил картинку из (185)... "это ж просто праздник какой-то"®
понятно, почему он против кнопки - места под кнопки больше нет

(226) " так один чувак в (196) напейсал: "Повысил права юзеров на документа и открываю их в режиме записи." Не знаешь того чувака?"
____________
Блин Кашпировский, а нельзя включить мозг, и подумать что права в конфигураторе можно дать на запись, но при открытии документа не давать возможность редактировать?

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

И соответственно никакого редактирования документов НЕ разрешается.
Но здесь же все Кашпировские , и знаю всё на свете

(230) добавь на форму справа внизу "version 0.8" и узбагойся уже

(230) Кашпировские знают не всё. но больных - видят :-) Некоторым больным даже могут помочь. Но не всем, ибо некоторые - неизлечимы.
однако смех продлевает жизнь...

(231) в паспорт.....

"Недоделанные отчеты - это не беда. главное - доделывайте детей, а то недоделанные дети вырастают и приносят недоделанные отчеты. И никак не разорвать этот порочный круг".
.
;-)

я на свои старые фейсы смотрю - и то вымораживает.. https://www.screencast.com/t/d2lw6yhg

Что вы все на человека накинулись? Что в УТ11 нет полей для серий/характеристик? Ну и тут те же самые яйца, только в профиль.
Только вот в режиме "на просмотр" это и в УТ не работает...
Хочется странного (редактирование в режиме просмотра) - пусть реализует. В чем проблема то?
Ёпрст на идею решения через Formex давал в этой теме. Не очень простое решение, но оно реализуемо.

(236) Меня давно терзала идея давать в конфигураторе права на запись доков и отказаться от штатных прав а ввести свои права.
Вот двойной клик и дал окончательный толчок этому. Открывать в режиме Записи, но мониторить права юзера - вот и сделал наконецто

И смелые есть тут кинуть мне конфиг 1с, в котором я поучусь не через ж... программировать?  )
[email protected]

(236) Вопрос в том как определить ячейку под координатами клика.

(239) СКАТ скачай https://www.33lab.ru/load/viewcategory/18.html
Но там много ВК выше WinXP не работают, так что в виртуалке запускай.
(239) Координаты МСЧ есть? Текущая строка есть? Текущая колонка есть? Пиксельные вычисления и т.д. и т.п. Это реально возможно.
Делал такое с Йоксель, там же нет интерактивного изменения высоты или ширины строки. Сделал!
Дальше сами, сами... Мне такая хрень с ТЗ открытой на чтение не нужна ;)

(239) Это точно никому не нужно. какой смысл

(240) Хочется от настоящих писателей, местных ). А что такое скат - поделка левая

(236) ну вообще-то, серии и херактеристики - это не атрибуты номенклатуры, а отдельные сущности, подчиненные номенклатуре. Т.е. атрибуты не номенклатуры, а экземпляра(ов) номенклатуры. Т.е. атрибут строки документа.
(239) (240) да говно-вопрос™. вотпрямщаз проверил, благо вчера поставил клюшки.
Все примитивно, прямо от мужика в кепке.

Процедура ПриДвойномНажатииЛевойКнопки(сост, х, у, ФСО)
ФормаРасш = СоздатьОбъект("РасширениеФормы");
Атр = ФормаРасш.ПолучитьАтрибутПоКоординатам(х,у);
Если Атр.Заголовок="МногострочнаяЧасть" Тогда
  ФормаРасш.УстановитьТекущуюЯчейку("МногострочнаяЧасть",х,у);
  текКол=Форма.ТекущаяКолонка();
  текСтр=НомерСтроки;
КонецЕсли;
КонецПроцедуры

(235)видимо, меня вчера https://prnt.sc/wkw9zn впечатлило настолько, что ночью приснился этот интерфейс, только текст на китайском (иероглифами), и портретом Мао.

(243) "ну вообще-то, серии и херактеристики - это не атрибуты номенклатуры, а отдельные сущности, подчиненные номенклатуре. Т.е. атрибуты не номенклатуры, а экземпляра(ов) номенклатуры. Т.е. атрибут строки документа."
Да, это в корне меняет дело

(244) Да, в корне меняет. ибо если включен учет по сериям - то без серий проведение запрещено.

(245) Блин. а если включен учёт по моделям, то без моделей проведение нельзя запретить ? ))

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

(240) Мне для общего развития :)
(241) Хотел было уже леща дать, но потом подумал, может это такой типа сарказм?
(243) Вот спасибо, хорошо. Похоже, что УстановитьТекущуюЯчейку() даже лишнее. ТС, аллё?! Это  именно то, об чём в (0).
Собственно, Майк десятком строк закрыл весь этот флуд на две с половиной сотни сообщений.

(247) Нуну, по барабану, что машины приниматься на складе не будут, главное что в учёте всё будет правильно. Лишний час /или день/ простоят, зато всё чётко, все модели разнесены

(248) УстановитьТекущуюЯчейку() какое это отношение имеет к (0) ?

(250) Эх ты... (с)

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

Можно!

>>Может различные формексы 1с++ ?

Да, формекс.

Конкретная реализация в (243). УстановитьТекущуюЯчейку() из того алгоритма я убрал (т.е. я проверил).

ЧЁ ТЕ ЕЩЁ НАДО? ━╤デ╦︻(▀̿̿Ĺ̯̿̿▀̿ ̿)

(251) Не верно увидел номер поста.
Я зделал через выдачу прав на запись. Так более правильно.

Семён Семёныч...

(252) MVC сломал, гоутушник

(47) Злопчинский, вот объясни чем плоха такая реализация:
https://prnt.sc/wm3whq
Изначально всё оприходование товаров идёт в документе. И соответственно манагеру удобно добавлять нужную дополнительную инфу (та, что не находится в самой ТТН,
а больше относятся или к товару или к покупаемой партии товара: модели товара, фото товар, серийники, штрихкод, ссылки на объявки товара на различных ресурсах и сетях: ютуб куфар авито и т.д.)

Т.е. после того как манагер непосредственно оприходовал  ТТН /количество и цены/ ему нужно заняться следующим этапом оприходования. И ему это удобно делать из этого приходного документа,
и соответственно именно в нём и была реализована эта возможность. /С чем тут все поголовно не согласны и доказывают что в приходном документе не должно быть ничего кроме инфы из ТТН/

В журнале приходов через подсветку можно контролировать "завершённость документа прихода".
Также есть обработки, одна из них на скрине выше, которая позволяет контролировать не заполненную инфу: модели, фото, штрихокоды ссылки и т.д.
И из этой обработки кликом попадаем в приход и опять же через двойной клик быстро заполняем те пустые ячейки, которые были изначально не заполнены.

Объясни мне, в чём тут проблема???? И каким образом этот безнес-процесс нужно переделать если он плохой??
Я понимаю смысл тратить деньги на переделку только если нужно достигнуть цель: чтобы манагер за единицу времени смог выполнять больше работы, т.е. его труд стал более эффективным.

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

(255) Я конечно, поотвык от клюшек, но у вас интерфейс на уровне вырви глаз - слишком перегружен ненужной инфой.

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

(248) ну, про процедуру я сказал в (179). Но дело не в обработке клика. Сделать, можно всё, что угодно - вплоть до робота, шарющегося по интеу и самостятельно ищущего недостающие характеристики. вопрос в том, нужно ли это делать.

(256) отличия между нами в том, что  1)я знаю, как работают бизнес-процессы на разных предприятиях, как они меняются внутри одного предприятия со временем (например, когда предприятие растет от 12 человек до 600), и проектирую систему так, чтобы при изменении БП (например, открытии удаленного склада, или филиала) работа не пострадала (и было минимум изменений в системах - учетной, взаимодействия, принятия решений, контроля). И более того, иногда предлагаю изменить БП для более эффективной работы (вчера, например, разговаривал об этом с собственнником бизнеса). 2) я знаю, как работают применяемые мной механизмы. 3)если я проектирую интерфейс - я стараюсь делать его простым (однозначным),  оптимизированным для работы "руками" (без мыши), и "шаговым" (не сделал текущеедействие - не сделаешь следующее. Делать можешь только то, что разрешено. и  т.п.). Другими словами, "я давно играю"
а вы работаете всю жизнь в одном ларьке, высасываете свои бп из в лучшем случае пальца, вместо их правильной организации - "автоматизируете бардак". и не представляете, как работают применяемые механизмы.
и понятие эффективности у вас - как у той секретутки, которая "эффективно" "печатает со скоростью 600 знаков в минуту - правда, такая фигня получается"©

"Автоматизируете бардак"
классное замечание.ок.

(260) особенно экстрасенсорные способности меня поражают

(262) потому, что я таких, как вы, видел достаточное количество. Поэтому вы предсказуемы.

(261) Автоматизируя бардак - получишь, в лучшем случае "автоматизированный бардак" :-)))

(262) это запросто. мне сколько раз говорили типа "мы только хотели попросить вот такую-то хотелку, а вы уже сделали.." вангуем и телепатируем.

Меня поражают две вещи. 1) Как же много необучаемых "спецов". 2) Находятся же люди, не будем показывать пальцем, которые со своих недосягаемых высот не утомляются объяснять и разжёвывать, и дожёвывать по нескольку раз одно и то же, ЧСХ, видя полную бесперспективность сих действий для конкретного индивидуума. И не раздражаются ведь! Долго. Поразительно. Некоторое даже отошли уже от этих клюшек совсем, но не устают делиться (не)древним знанием. :) Несомненная польза есть для третьих участников, сторонних наблюдателей и последующих археологов. Памятники при жизни надо ставить таким людям и премии выдавать. Хотя конкретно эта тема и зафлужена до безобразия.

(266) ТС не "спец". он дирехтур. который в силу разных причин (на мой взгляд, трех) не привлекает программистов, а "напейсает" сам.

(267) Ок, тогда в (266) "спецов" надо заменить на "писцов"... или совсем "песцов". ໒( ͡ᵔ ▾ ͡ᵔ )७

(268) тут другое. "беда, коль сапоги начнет тачать пирожник, а пироги печи сапожник..."©

(269) Да, кстати, помню, работал с одной веб-дизайн конторой. Я делал со стороны снеговика, а директор этой конторы лично тачал "дизайн".  Хорошо хоть, что я и в пхп могу. Это был трэш.