Скачал обработку, только открыл код - вижу:

Если не Начисления.Открыта()тогда
Сообщить ("Блин!");
КонецЕсли;

а вы какие забавные комменты видели?

в юмор же постил че за фигня?!

//****search for truth ****** XX-06-2014****
// нельзя смотреть без смеха или слез            (Т_Т)
Процедура КнопкаВыполнитьНажатие(Кнопка)
    
    РассчитатьПлатежи();
    
    РасчетРеквизитов();
        
КонецПроцедуры

(0) Зачем ты копаешься в моём коде?

В типовой торговле 7.0 на всю жизнь запомнил основной принцип главного разработчика:
// Здесь есть некоторая натяжка, но так уж сделаем!!!!!

у нас есть например такое
...
    |        ИЗ
    |            РегистрНакопления.ЗаказыПокупателей.Остатки(
    |                    &Дата,
    |                    ДатаОтгрузки > &ПолетГагарина
...
Запрос.УстановитьПараметр("ПолетГагарина",Дата(1961,04,12));

(5) ))))

+
        Если Стр.ВидКомпоненты = Перечисления.ВидКомпоненты.АльтернативнаяГруппа Тогда
            Сообщить("Ахтунг-Ахтунг! Обнаружили входимость АГ->АГ!", СтатусСообщения.ОченьВажное);
...

(1) вот и твое Сообщить ("Блин!"); сработало ^^

А меня как-то удивил ответ от 1С на наше письмо об ошибке в УПП. Смысл был, что "мы ошибку исправим, но вообще-то не думали, что этим кто-то будет пользоваться".

(9) а ты думал, как типовые пишутся? )

Иначе
    Отказ = Истина;
    Сообщить("Не понятная ошибка. Обратитесь к администратору 1С.");
КонецЕсли;                

Есть у меня и такая закладка, когда согласующих окажется меньше нуля. Уже лет пять не всплывала.

(11) ошибка как раз понятная,
http://petrograd.biz/gramota/18.php
обратитесь к репетитору по русскому языку

//<<<--- ДОП. быдло-код Максима.

(12) Моим татарам на русский язык 30% скидки приходится давать.

(5)А че вы претесь? У нас на кассах такой пароль был, когда я в сети магазинов работал. :)

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

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

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

(16) да уж, мат, пожалуй, уберу. пускай он навсегда останется в памяти... хранилища...

(15) А у нас 220641

(5) ерунда какая-то....

(18) Я так преносимые данные помечал, чтобы после удалять без проблем. Типа строки префикса "@#$%^&" в комментарии.

Если <....> ИЛИ Истина Тогда//не пойму зачем это, им это не надо

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

Если <....> И Ложь Тогда //сделал, чтобы не распределялось. Криво распределяется.

Движения1.Записать(,);//Не поможет, нужно пересчитать налоги

(12) Ну да, конечно. Подразумевалось "Произошла не понятная в такой ситуации ошибка, а непредсказуемая xерня".

(22) Не, там рожицы из таблицы символов в юникоде. Просто всех смотрящих в ступор это вводило, а я со злости всё исправил на человеческий язык

// потом доработать
встречалось неоднократно :)

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

(27)>>который валится от одного чиха
чтобы в 1с ничего не валилось, нужно ох как все проработать. Обычно даже не во времени дело - просто некому.

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

(28) Ну как некому, мне ж пришлось разгребать :)

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

натыкался на такой комментарий
//наконец-то разрешили убрать эту фигню! УРА!
и далее закомментирован код оповещения по поводу конфиденциальности информации

(0) я не считаю это забавным
я считаю это непрофессионализм

(32) всем программистам ходить строем и НИКОГДА не ржать!

(33) зануды атакуют

(34) если бы такую херь как в (0) ты бы встретил в типовом продукте от 1С чтоб ты сказал? Или пусть даже не от 1С а просто в чьем-то коробочном решении

(35)
- Как сложно жить среди занудов! - сказал трёхлетний Михаил. - Среди зануд! - поправил Павел, тридцатилетний и в очках.

(35) Ты наверное, никогда не встречал продуктов от Раруса :)))

это не занудство, это понимание когда юмор уместен а когда нет

(38) Юмор уместен везде!

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

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

Если комментарии в рабочей базе такие, руки оторвать тому кто их написал

(40) Если надо чтобы в итоге код был официозным, то надо сразу делать официозным. Знаем мы эти "а, потом напишем как надо..."

(36) плохой пример - детей лучше сразу поправлять что потом не пришлось переучивать говорить правильно

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

(0) И что тут смешного? Довелось мне как-то править код, где проверка выполнения запроса выглядела так:

Если Запрос.Выполнить(ТекстЗапроса) = 0 Тогда
сообщить("Увы!");
КонецЕсли;

Это тоже, по-твоему смешно??? Тупость... Непрофессионализм...  Но не юмор.

"Юморить" в коде никто не запрещает. Но это не должно мешать работе пользователей и разработчиков.

Реальный пример: отчет, в котором куча цифр. В определенной ячейки установлена расшифровка. Тыкаемся в эту ячейку, программа пишет "И что ты тут хотел увидеть?".

(46) Ну нормально, у меня такое тоже есть

(17) Поиск по коду - это страшный моветон. Если уж не получается предопределенные значения использовать - то искать надо либо по наименованию, либо по реквизитам.

(23) Это делается для быстрого отката изменений. Убрал абсурдное условие - и получил оригинальный функционал.

(35) а это херь Приколы в комментариях от разработчиков типовых конфигураций ?

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

(51) Потому что когда ты сделаешь новую базу - совсем не факт, что нужный код совпадет с нужным элементом или что он вообще будет. А вот если они название поменяют - приезжаешь, даешь по рукам и берешь денежку за вызов. А если ты фикси - то если не находишь элемент по наименованию (или находишь более 1) - выдавай предупреждение. Или вообще проси выбрать нужный элемент вручную ;) Очень быстро отучает от самодеятельности.

(9) можно подробнее про ошибку

(52) Да лучше всего просто такие вещи не использовать. На ИСе видела статью про использования свойств для таких случаев, но прочитать не настроилась.

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

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

(54) Да, заводишь свойство в ПВХ "Свойства объектов", и назначаешь нужному объекту нужное свойство. Это тоже один из вариантов. Но по-хорошему, даже в этом случае надо обрабатывать ситуацию, когда нужное свойство не найдено. Если же ты еще и предложишь им выбрать в таком случае - то это уменьшит остроту проблемы, и можно будет ехать к ним не очень срочно.

(56) Юзер испортил данные, причем здесь франч?

(58)Было у меня одно чудо, у которого сдельная зп перестала считаться потому что пришел новый ГБ и цех "матрацный" переименовал в "матрасный" :) Кто виноват в таком случае?

(58) Замечательная отмазка.
Вызываешь такой водопроводчика трубу поменять, а он стыки пластилином замазал, через пол года потекло, но он же не причем.
Привязка к наименованию мина замедленного действия.

(59) В ТЗ что было написано? Вот то и правильно.

(60) Ты же сам попросил его замазать их пластилином, потому что нормальный ремонт дорого. Ну и кто тут виноват?

+(60) А поиск по коду - вообще диверсия.

(61) Я не знаю, что было в ТЗ, я пришла к уже неработающей обработке.

(63) Ну и тут 2 варианта решения: дешевый и правильный. Какой выберет клиент? ;)

(61) Зачем мне это простить пластилином замазать. Вызываю устранить проблему. И надеюсь, что специалисты знают свое дело, и сделают по уму. Выставят цену, оплачу. А чем там замазано им решать, не мне.

(65) Ларечники за правильный вариант решения платить не будут... им как называешь цену - так сразу "А нельзя дешевле?"

(62) Не говорю, что поиск по коду решает дело, но код всё-таки намного реже меняют.

(66) Скупой платит дважды...

(64) еще бывает ленивый вариант, когда "я не хочу никакие настройки, я хочу чтобы сразу было вот так, ибо я точно знаю, что эти условия никогда не изменятся". Это хуже всего

Что вы понимаете в чужих комментариях...
Я вот, например - ничего :(

//STOK KART OLU?TURULDU**************************************************************//
                
//STOK KART ?ZELL?KLER?N? OLU?TURMAK GEREK?R*****************************************
//?LK ?NCE KEND? KART L?STELER?NDE ??ELER? ID'YE G?RE BULMAK GEREK?R

(69) Молитва

елочка нарисованная в коде. красивая такая с игрушечками а внизу подпись: с новым годом :)

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

(70) скорее шаманство)

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

есть код отлова бухов с шаловливыми ручонками

Процедура ПриРедактированииНовойСтроки()
    //проверим и запретим копирование
    ТЗТЧ=СоздатьОбъект("ТаблицаЗначений");
    ВыгрузитьТабличнуюЧасть(ТЗТЧ,"Товар");
    ТЗТЧ.НоваяКолонка("К","Число");
    ТЗТЧ.Заполнить(1,,,"К");
    ТЗТЧ.Свернуть("Товар","К");
    стр=0;
    ТЗТЧ.НайтиЗначение(Товар,стр,"Товар");
    ТЗТЧ.ПолучитьСтрокуПоНомеру(стр);
    Если ТЗТЧ.К>1 Тогда
        КопируютЦуки=1; // вот оно, жемчужное зерно :)
    КонецЕсли;
КонецПроцедуры

ЗЫ. © ® Guk :)

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

P.S. Вы, видимо, просто не работали в крупных компаниях, где может быть несколько независимых баз на основе 1 конфигурации. Иначе недостаток поиска по коду был бы очевиден.

(68) Это от непрофессионализма. Я даже если и ставлю поиск по наименованию (потому что заказчик требует как можно дешевле) - то проверяю результат поиска. И если не найден - пишу юзеру что надо сделать (вернуть такое-то название взад). Если он это не может - то выезд специалиста на место платный. Хотя часто проблема решается по телефону - юзер говорит сообщение, я говорю ему что делать.

(69) Дык для начала надо язык определить ;) Гугль считает, что это турецкий.

(72) Опытный программист знает об этом и должен предупредить. Ну а дальше заказчик сам решает: дешево делать или правильно. Как скажет - так программист и сделает. Главное, чтобы заказчику были объяснены возможные грабли дешевого варианта.

(75) Я и без гугля знаю, что это турецкий. Легче жить от этого не становится :)

(75) Я бы увольнял сразу таких "гениев", которые привязываются к наименованию.

(46) >>"Юморить" в коде никто не запрещает.
Тока не все юзеры этот юмор понимают.

(79) А что юзеры забыли в коде? О_о

(77) Дык гугль в помощь :)

(78) Это все от узости мышления. Далеко не всегда для заказчика будет выгодным внедрение системы хранения доп. настроек. Да и не всегда цементирование ссылки обосновано.

(78) к чему-ж привязываться? к наименованию - нельзя, к коду - преступление.. к чему ? к ID ?

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

(82) Я не говорил, что к коду нельзя привязываться.

(80) Ну я имел ввиду тексты сообщений, они же в коде прописаны.

(84) дык в (62) прямо ультимативно определено отношение к поиску по коду :)

(83) И? Так в исключительных случаях, или, все же, сразу увольнять? Привязку по наименованию я сделаю за 0,5-1 час. И каждое изменение будет у меня стоить 0,5-1 час (или меньше, если это печатная форма, которую постоянный клиент вставит сам из письма в электронной почте). В то же время, за систему доп. настроек я возьму как за 3-5 часов. Т.е., за стоимость системы доп. настроек, которые, как показывает практика, все равно приходится обслуживать программисту в 90% случаев, можно поменять название 5-10 раз. И кто тут кого разводит?

(86) Читай (52) и (75). У человека задача: обеспечить себе максимальное количество выездов к заказчику по каждому чиху. А поиск по коду, его этого хлебушка лишает :)))

(81)ты уж определись, то пишешь, что иногда надо использовать поиск по наименованию, то пишешь, что только поиск по наименованию надо использовать) скоро скатишься и таки согласишься, что был не прав) Поиск по наименованию ИМХО глупость, согласен, что бывают ситуации когда его приходится использовать, особенно в глупо написанных самописках...

(88) Хрень ты написал. Поиск по коду другими программистами как раз часто дает дополнительный гешефт при решении проблем "что-то 1С глючит, посмотри..."

(87) "Привязку по наименованию я сделаю за 0,5-1 час" - ты полчаса-час пишешь фразу "НайтиПоНаименованию"? Понятно :))

(89) Чего определяться? Все зависит от конкретной задачи и желания заказчика. Ситуации, они разные бывают.

(91) Выезд к заказчику, составление ТЗ. Плюс там не одна строчка НайтиПоНаименованию(), но и обработка ситуаций "Ничего не найдено" (с сообщением пользователю как исправить) и "Найдено более 1 элемента" (тоже с сообщением как исправить). Плюч это найденное значение надо использовать где-то.

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

(93) Заказчик сам выбирает у меня, какой вариант он хочет. Так что не надо тут про франчей.

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

Если есть просто НайтиПоКоду("00043") без комментариев - то ты просто можешь даже не узнать, что там вообще по коду искалось. А вот НайтиПоНаименованию("ООО Жадина") - будет понятно всем.

(94) Написан полный бред. Там, где пользователю разрешено менять наименование - НЕЛЬЗЯ использовать поиск по наименованию. Там, где пользователь МОЖЕТ изменить код, соответственно НЕЛЬЗЯ использовать поиск по коду. А франчи стараются сделать всё попроще, а бабла срубить побольше.
И по поводу "Заказчик сам выбирает у меня, какой вариант он хочет" - заказчик в большинстве случаев вообще не разбирается, как ты там ищешь элемент. Заказчику нужно, чтобы всё работало БЕЗ вмешательства программиста.

(94)надо придерживаться рекомендаций 1С почитай

(95) Не надо про большинство случаев - в моем случае заказчику описываются преимущества и недостатки обоих вариантов. Более того, 1С не поддерживает в 8.2 раздельный контроль записи по полям. Так что если пользователь может менять наименование - то он сможет поменять и код. И наоборот. Мне, конечно, выгоднее сразу за 5 часов срубить денег и не ездить потом по мелочам к клиенту, так что и тут ты не прав.

(96) 1С сама не придерживается своих рекомендаций ;)

(97) "Так что если пользователь может менять наименование - то он сможет поменять и код. И наоборот." - сам то понял, что написал? Каким образом он сможет поменять код, если я закрою ему эту возможность? :))

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

(99) Во-первых, раз уж у тебя, как разработчика, стоит задача закрыть возможность изменения данных, ТЫ и должен предусмотреть всё, в том числе и запуск обработок. И во-вторых: по поводу "в типовых конфигурациях код поменять можно" - читай  (95) до полного просветления.

Сами оставляли комментарий

//оставь надежду всяк сюда входящий
+ troll-face acii-символами

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

(100) А с чего ты взял, что у меня такая задача стоит? Если заказчику надо немного поменять печатную форму, например, для одного-двух контрагентов или огранизаций и только - он что, должен потом платить за обновление нетиповой конфигурации потому что специалист оказался неспециалистом и включил возможность изменения, не предупредив заказчика о последствиях?

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

(102) Ты видимо (95) так и не осилил. За сим заканчиваю бесплодный спор ни о чём.

(103) В (95) лишь твое частное мнение. Удобное, чтобы с заказчика побольше денег содрать.

(104)главное уметь отстоять свой ховнокод)))

(104) Я не франч, поэтому передо мной стоит задача писать РАБОТОСПОСПОСОБНЫЙ код, максимально защищённый от действий пользователей.

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

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

Спор ради спора - обычно просто предупреждаешь - пожалуйста не меняйте то-то, а то обработка перестанет работать. Очень часто в обработках тч например давай выбор - равносильно дать гранату юзеру, да и не нужен он там. А включать изменения ради плевой обработки - идиотизм.
Так где порграммиорвание как искуство - там да. не надо всяких НайтиПо...., а жизни очень и очень часто используются.

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

(105) Да вот типовая ситуация: заводят новую базу, а за перенос данных и начальных остатков платить не хотят (часто даже тебя не зовут, а какой-нибудь мальчик тупо загружает конфигурацию в пустую базу). Поиск по коду - в пролете, фиг знает под каким кодом будет "ООО Жадина" в новой базе и кто будет под этим кодом вообще, и без доп. настроек функционал с системой интерактивной настройки тоже работать не будет. А по наименованию вобьют - и все заработает.

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

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

(110) Мне не предъявят, т.к. программист не отвечает за достоверность данных в системе :))

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

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

Я не фикси и работаю с множеством клиентов. Проблем с "найти по коду" не припоминаю.

(109) эт в каких франчах считают, что за переделывание доплатят?

(110)проблемы этого мальчика. И что тебе мешает сделать в обработке страничку с настройками и если там ничего не заполнено, заполнять НайтиПоКоду, в итоге даже при переносе этим мальчиком, если поля будут пустые, они могут ручками заполнить поля 1 раз, нажать сохранить настройки и усе

(112) Дык те предъявят: в ТЗ было сказано, что если клиент - Иванов, то сделать то-то и то-то. А тут клиент - Петров. Программа работает неправильно.

(113) У меня это 1 настройка, где все соответствия лежат. Редактируется так же 1 обработкой. Плюс опционально общий модуль с функциями для получения и записи настроек.

(115) Проблема будет моя, ибо тот мальчик сольется, а что моя доработка не работает предъявят мне.

+(115) 2. Мне ничего не мешает, у меня есть такая обработка. Просто если клиент не хочет за это доплачивать - я ему что, бесплатно это делать должен?

(116) " в ТЗ было сказано, что если клиент - Иванов, то сделать то-то и то-то" - я, в отличие от жадных франчей, не берусь выполнять любые тупые хотелки. А тут сама постановка идиотская.

(119) И тем не менее, таких хотелок очень много. И часть из них даже обоснованная.

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

(120) Алгоритм, завязанный на наименовании - изначально глуп и не имеет никаких обоснований.

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

(122) Крупный (по меркам организации-заказчика) клиент выдвигает свои требования по оформлению документов. Хранить соответствие по ссылке - в каждой базе придется делать настройку после заведения этого клиента, по наименованию - придется менять после смены им наименования, по коду - придестя в каждой базе заводить этого клиента и контролировать его код. И? Все 3 варианта имеют свои недостатки.

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

(124) У него макет свой, а не ответственные лица. Плюс в макете еще и штрих-код для автоматизированной обработки по правилам именно этого клиента. К тому же, ответственные лица к контрагенту не привязаны.

(125) Да уж. Прямо нерешаемая задача, кроме как привязываться к наименованию. А потом у контрагента меняется наименование - и твоя программа перестаёт работать :))

(126) Это был пример хотелки, когда надо привязаться к конкретному контрагенту. А в (123) я уже описал 3 варианта привязки, каждый из которых имеет свои недостатки. И какой из них выбрать - зависит от ситуации у заказчика.

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

(127) Ага. т.е. ты уже признаёшь, что поиск по наименованию - самый плохой из всех?

(128) Самый плохой - поиск по коду. В нем нет смысла: он ничем не лучше ссылки, но с ним больше возни, чем со ссылкой. А поиск по наименованию в определенных ситуациях лучше ссылки.

(129) Самый плохой - поиск по наименованию. В нем нет смысла: он ничем не лучше ссылки, но с ним больше возни, чем со ссылкой. А поиск по коду в определенных ситуациях лучше ссылки.

Твой пост и мой по смыслу абсолютно идентичны, т.е. бессмысленны :))

(130) Типичный пример пользы поиска по наименованию - это
1) разные независимые базы будут работать без доп. настройки
2) через 5-10 лет "ООО Жадина" будет гораздо информативнее "00043" или ссылки, по которой объект не найден.
3) когда поиск в наименовании ведется по подстроке (например, надо применить особый порядок ко всем контрагентам группы компаний с похожими названиями) - в этом случае можно 1 подстрокой описать всем существующих и будущих контрагентов.

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

(114) закрываешь же часы. или бесплатно поедешь?

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

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

(134) 1. Это другое юр. лицо будет уже считаться. Уж кто-кто, а бухгалтер это должен знать.
2. И в фикси люди регулярно сменяются, плюс память у людей не идеальная. Что "00043" значит они и не вспомнят через несколько лет... а то, может, уже и не надо это никому, а в конфигурации лежит, мешается.

(135) Ты это бухгалтерам объяснять будешь насчет ссылок ;) Они, может, его специально переименовали, чтобы проверка больше не срабатывала.

(136) Уж кто-ктото, а любой бухгалтер знает, что юрлицо определяется ТОЛЬКО по паре ИНН/КПП, но никак не по наименованию :))

(137) Зато хороший бухгалтер знает, что ИНН/КПП может и поменяться ;) Например, при переводе юр. лица в другую ИФНС. Кроме того, если работаешь с более-менее крупным юр. лицом, то в справочнике контрагентов ему может соответствовать более 1 элемента ;) И вот тут название начинает играть рояль.

(137) По-хорошему, юр. лицо определяется по коду ОГРН.

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

(140) В базе им следует дать отличающиеся друг от друга названия во избежание путаницы пользователей ;) Именно для этого есть наименование, а есть полное наименование.

(131) А вот лично я предпочитаю в данном случае добавлять константы.

(131) опередил

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

оп. это я на (142) написал

(143) Хотя некоторым и не нравится такой подход. Тоже есть недостаток - констант может дофига стать.

(143) Дык задешево не гомнокод не получится. А грабли можно поймать при всех способах.

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

(141) Вот именно. И по этой причине поиск по наименованию является неприемлемым для контрагентов.

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

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

(66) а зачем изначально не правильный вариант предлагает?? это же обман..

150+ неправильный..

(150) Какой обман? Им так и заявляется: хотите дешево или правильно? Выбирают они. Не все готовы 5-10 тыр. выложить за такую доработку. Тем более когда мальчик со стороны может за 500 руб. все сделать. Обманом как раз будет не сказать про дешевый вариант.

Если мГруппыСклад.Получить(СтрокаДанных.Группа) <> Неопределено Тогда
                СтрокаДанных.ОтработаноМинут = СтрокаДанных.ОтработаноМинут - Обед - Перекуры; // люмпены
            Иначе
                СтрокаДанных.ОтработаноМинут = СтрокаДанных.ОтработаноМинут - 60; // планктон
            КонецЕсли;

(152) Обман в том, что твой "дешёвый" вариант выходит для заказчика гораздо дороже "правильного", т.к. требует постоянных доработок.

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

(149) мы рассматриваем ситуацию в (87). перестал работать поиск по наименованию - оплатите полчаса.

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

(155) "ошибки которые могут случится раз в три года стоит ли думать о них сейчас" - всё зависит от критичности ошибки.
Если ошибки связаны с потерей денег, то тут надо продумывать по максимуму, чтобы их избежать даже раз в 5-10 лет.

(154) Не обман. Я его сразу предупреждаю, что если что-то вдруг потребуется изменить - нужно будет еще деньги платить. А при правильном варианте - нет (точнее, только оплатить время консультации по телефону, т.к. 99% вероятность, что инструкцию по настройке они потеряют).

(157) А с чего ты взял, что я не работаю с производством? У меня индивидуальный подход к клиенту ;)

(157) Кстати, а вы-то что до сих пор НайтиПоКоду используете, если такие опытные?

(159) "Я его сразу предупреждаю, что если что-то вдруг потребуется изменить - нужно будет еще деньги платить" - а ты предупреждаешь, что при твоём подходе, что-то изменять потребуется постоянно и часто? :))

(159) "инструкцию по настройке они потеряют" - никогда тебе не говорили, что обычно принято писать справку, которая вызывается волшебной кнопочкой F1? И потерять её можно только потеряв саму программу?

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

(162) Дык чтобы по F1 вышла нужная справка - надо сначала открыть нужную обработку ;) В инструкции как раз и описано, как ее найти и открыть.

(152) логика хромает читая "дешево или правильно"..  
Если не "дешево", то "неправильно" - вот что читается в твоем сообщении..

с тобой сам захромал... в общем, ты негодяй)))

(165) Просто человек на подсознательном уровне понимает, что искать всё и вся по наименованию неправильно, но оправдывает свой неправильный подход, как последний аргумент, дешевизной. :)

(166) А вот тут уже вы сами нафантазировали. Не было у меня ничего про "искать всё и вся по наименованию". Я как раз писал, что от ситуации зависит, как привязывать.

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

(163) Про галочку "включать в содержание справки" когда-нибудь слышал? Ставишь её - и о чудо! пользователь увидит твою инструкцию в любом месте, вызвав справку.

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

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

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

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

(172) Мне выгоднее получить деньги сразу в 10-кратном размере. Но не все соглашаются.

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

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

(175) 90% выбравших дешевый вариант обращаются не чаще раза в год, еще около 5% после 2-3 раза просят переделать на правильный. И только оставшийся мизер упорно жмет деньги, плятя за каждый вызов. А ты с клиентов брал бы со всех 10-кратную стоимость, да еще и включал бы возможность изменения в конфигурации, т.о. они попадали на бабки за регулярное обновление конфигурации. Нормально, чо.

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

(177) Дык я уже писал выше про узость взглядов. Просто есть разные варианты. Кто-то может позволить себе содержать программиста 1С в штате (в этом случае, кстати, злоупотребление НайтиПоКоду() - это неправильный вариант), а кто-то - нет. И у них разные подходы к затратам на обслуживание 1С. И объемы у них тоже разные.

Обновление типовой конфигурации пользователь может произвести сам. За нетиповую ему придется платить.

О чем сырбор. Бывают разные случаи в каких то лучше Константа, в каких то НайтиПоКоду в третьих ПоНаименованию.
Бывает удачный выбор когда что использовать бывает неудачный можно привести кучу доводов как в защиту так и против любого из методов. На то вы и програмисты чтобы выбрать в каждом конкретном случае оптимальный вариант.