Пример изменения стандартных конфигураций с откатом

Опубликовал Владимир Полевик (pvvpvv) в раздел Программирование - Практика программирования

Данная обработка решает конкретную задачу - привязка основных менеджеров конфуграции УТ к основным документам через свойства.

Данная обработка решает конкретную задачу - привязка основных менеджеров конфуграции УТ к основным документам через свойства.

Скачать файлы

Наименование Файл Версия Размер
Пример реализации
.1252770392 9,01Kb
25.09.09
34
.1252770392 9,01Kb 34 Скачать

См. также

Добавить вознаграждение
Комментарии
1. Александр Зубцов (iov) 358 12.09.09 19:59 Сейчас в теме
2. Владимир Полевик (pvvpvv) 9 12.09.09 20:22 Сейчас в теме
3. Maniac (Eugeneer) 12.09.09 20:44 Сейчас в теме
И что это решает? ЦРМ нарушен, отчета нету.
Привязать менеджера к доку это вообще не проблема.
4. Владимир Полевик (pvvpvv) 9 12.09.09 20:52 Сейчас в теме
Цитата -

Maniac 05.09.2009 19:04:24

(8) а что ты ищешь. Что тут решать?
Добавить в документ поле Менеджер (или представить). Ссылку на физ лица. и всё. считай все готово. В УТ только один документ продажи Реализация.
После добавления реквизита считай что и отчетность вся готова, потому что можно в любом отчете группировку вытянуть.
Цена ? да тысячи 2 максимум.

Жизнь другая.
5. Maniac (Eugeneer) 12.09.09 21:09 Сейчас в теме
(4) Да но там же потом кто то озвучил потребность именно в соблюдении отчета Показатели работы менеджеров.
6. Maniac (Eugeneer) 12.09.09 21:18 Сейчас в теме
Посмотрел модуль. жэсть какая. этож надо было столько кода писать на элементарнейшую задачу поставить свойство в документах.
7. Владимир Полевик (pvvpvv) 9 12.09.09 21:31 Сейчас в теме
Дополнение (для тех, кто понимает(5-6)) - единственное, что надо, в данном случае, сделать вручную, это создать общий модуль "" и назначить ему свойства. ыло
(5) - отчет можно написать любой. было бы на чем писать.
8. Maniac (Eugeneer) 12.09.09 21:32 Сейчас в теме
А кто автор разработки реальный? Ему плюс поставить за механизм изменения.
9. Maniac (Eugeneer) 12.09.09 21:35 Сейчас в теме
Касаемо менеджеров конечно не согласен по поводу решения через свойства. а вот механизм изменения прикольный.
Так можно и любые изменения фиксировать в одной обработке,а потом при обновлениях запускать обработку и всё. Гемморно конеч все двойным путем регистрировать зато безошибочно. Автору (кто реально написал) данной разработки однозначно плюс.
10. Владимир Полевик (pvvpvv) 9 12.09.09 21:36 Сейчас в теме
11. Владимир Полевик (pvvpvv) 9 12.09.09 21:59 Сейчас в теме
12. Владимир Полевик (pvvpvv) 9 12.09.09 22:02 Сейчас в теме
(9) а через что решать меджеров?
13. Maniac (Eugeneer) 12.09.09 22:41 Сейчас в теме
Через то что является измерением нужных регистров, либо реквизитом измерения регистров.
Это либо проект, либо любой реквизит документа заказ покупателя (если все операции проходят через заявки), ответственный, проект, либо свое поле.
Свойства это канечно круто, но как бы не нашлось таких мест где придется получить геммор.
Не забываем что в виртуальных таблицах регистров регистратора нет. Соотвественное свойства документов не везде можно использовать. Придется делать объединения, чуть более сожные запросы. что необратимо скажется на производительности.
14. Maniac (Eugeneer) 12.09.09 22:42 Сейчас в теме
+(13) про заказ покупателя я привел пример потому что заказ покупателя является измерением тех регистров где потребуется выборка по менеджеру (регистр заказы - без комментариев, регистр продажи, продажи себестоимость)
15. Maniac (Eugeneer) 12.09.09 22:51 Сейчас в теме
И взаиморасчеты.
Короче для идельного решения данной задачи нужно так:
1) все взаиморасчеты вести по договорам в режиме По заказам.
2) все сделки должны проходить чере заказ.
3) в заказе использовать: а)либо проект б) ответственного в) свой добавочный реквизит. На обновления этот реквизит никак не скажется.
4) исходя из этого придется всего навсего изменения сделать по документу заказ покупателя (больше нигде ничего трогать не надо, как у вас все модули)
5) всё. таким образом практически по всей базе решится одним махом весь вопрос. Всего нужно будет контролировать один документ (даже в реализациях ничего не надо). Во всех отчетах автоматом без потери производительности уже все будет готово.
Группировка и отборы делаются через реквизит ЗаказаПокупателя.
Нет потери производительности, можно писать свои любые отчеты, запросы с виртуальными таблицами регистров без геммора.
К минусам которые под собо ведут свойства я думаю понятны. Еще можно добавить такой геммор который может обломать многое. это возврат. В возврате свойствами ты не проставишь торгового представителя на каждую строку. А ведь может получится большой возврат по нескольким сделкам. Что будешь делать? разбивать на кучу документов?
Короче граблей не оберешся. В типовой учет по сделкам есть, реализован через заказы. Вот и делай в заказе чо надо. и все будет решено.
16. Maniac (Eugeneer) 12.09.09 22:56 Сейчас в теме
А уж поверь. менеджеры это очень тонкая штука. И очень требовательная. На своем опыте могу сказать что надо думать на будущее и видеть грабли решения. Твое решение принесет грабли в будущем. Менеджеры имеют тенденцию придумывать кучу задумок и не завтра - послезавтра придумают такое где свойства не помогут.
Так что копай. Мое предположение что надо изменить именно ЗаказПокупателя и больше ничего не трогать. Ну и работу соответственно перевести в этот режим.
17. Maniac (Eugeneer) 12.09.09 23:07 Сейчас в теме
Ты в курсе кста что через свойства ты ни один отчет не получишь по регистрам?
Взаиморасчеты никогда в жизни не получишь.
Продажи тоже.
В типовой отборы и группировки можно делать только по категориям ( и то для этого используется универсальный отчет, который отслеживает галку Использовать свойства и категории, и епошит код к основному запросу)
А категории это вообще отдельная песня.
По свойствам полный отсос. Так шта думай. Если все твои решения прогорят а мой вариант будет рабочим с тебя 2 штуки :)) не забывай.
18. Владимир Полевик (pvvpvv) 9 12.09.09 23:09 Сейчас в теме
Я, не хочу вступать в диссссскусию. Я, привел элементарный пример решения задачи. Если есть решения проще - выкладывайте.
19. Maniac (Eugeneer) 12.09.09 23:12 Сейчас в теме
(18) разработка в сабже супер по изменению конфигурации. Все мои высказывания касаются http://infostart.ru/orders/943/. Может мне не тут надо было писать, заранее приношу извинения.
20. Владимир Полевик (pvvpvv) 9 12.09.09 23:13 Сейчас в теме
+(18) только не говорите, что оператор должен что то делать.
21. Maniac (Eugeneer) 12.09.09 23:13 Сейчас в теме
сам спросил в (12) вот я тебе и ответил. Твой элементарный пример в конкретной задаче по менеджерам нерабочий, тоесть ни к чему не приведет хорошему.
22. Владимир Полевик (pvvpvv) 9 12.09.09 23:17 Сейчас в теме
(19) А я, не от чего не отказываюсь.
23. Maniac (Eugeneer) 12.09.09 23:20 Сейчас в теме
(22) см 15.
Определись что будешь использовать в заказе. ответственного, проект либо свой реквизит.
Допиши строчку
ВыбранныйРеквизит = КОнтрагент.ОсновнойМенеджерПокупателя.
Ну или как там у тебя сделано, только без свойств.
Всё. задача решена.
24. Maniac (Eugeneer) 12.09.09 23:22 Сейчас в теме
Все отчеты готовы к использованию. полностью. вплоть до взаиморасчетов.
Показателиработы менеджеров перепишешь с выборки из контрагента на выборку из заказа.
Главное в этом всем это установить режим договоров по сделкам и по заказам.
Ну так фактически у тебя и обстоят дела.
25. Maniac (Eugeneer) 12.09.09 23:25 Сейчас в теме
Это позволит разделять на менеджеров даже без установки в контрагентах.
Может потребоватся когда манагер свалит в отпуск а сделки должны будут перейти тому кто будет работать. Тоесть без геммора с карточками.
А если заказы делают сами манагеры то там вообще можно сделать заполнение реквизита текущим пользователем.
26. Владимир Полевик (pvvpvv) 9 12.09.09 23:28 Сейчас в теме
я утомился.
Ты, программу читал?
Какие реквизиты?
Ты запускал Ут?
Все происходит на ФОНЕ. Оператор отдыхает.
27. Maniac (Eugeneer) 12.09.09 23:29 Сейчас в теме
из (25) можно сделать вывод что вообще не требуется никаких программных изменений. Если выбрать Ответственного и заявки делают менеджеры, тогда ответственный = манагеру который сделал сделку.
Вывод всего этого можно сделать один: задача полностью типовая! и ложится под логику учета. Даже события будут работать по отвественному.
И вся отчетность.
28. Maniac (Eugeneer) 12.09.09 23:33 Сейчас в теме
(26) похоже мы на разных языках говорим. Я тебе говорю не про твою разработку. а про задачу про менеджеров. Причем тут твоя разработка. она нормальная. делает обновление модулей все супер.
Извини что наспамил про менеджеров. ты вроде искал решение по той задаче. вот я тебе и отвечаю по ней непосредственно.
Если уж говорить про разработку. она не универсальная, заточена под конкретную задачу. Вот мы и обсуждаем эту задачу.
Хочешь обсуждать разработку? ну так напиши универсальный алгоритм, либо вырежи код привязанный к твоей задаче и выложи чисто разработку с алгоритмом обновления. Тогда и обсуждений не будет.
29. Maniac (Eugeneer) 12.09.09 23:33 Сейчас в теме
Все. С празником наступающим! Удачи.
30. Владимир Полевик (pvvpvv) 9 12.09.09 23:33 Сейчас в теме
(27) Ответственный - другой человек.
31. Maniac (Eugeneer) 12.09.09 23:39 Сейчас в теме
(30) только не говори что автор. Это заблуждение.
А больше и быть некому. 90 процентов делают ошибку когда думают что в ответственном должен стоять обязательно автор.
Там должен стоять именно манагер.
У тебя ошибка которую ты сделал и пытался описать в той ветке, это то что ты ставишь группировку из КОнтрагента (основной менеджер) и получаешь данные за весь период и у тебя выдается тот манагер что стоит текущим в карточке контрагента. ВОТ ОШИБКА. это неправильно. основной манагер в карточке это тупо справочная информация. Методика УТ подразумевает ведения учета ПО СДЕЛКАМ. конкретным. у сделки есть ответственный. Это и есть твой торговый представитель который должен там стоять и которому принадлежит продажа.
А ответственный это не автор. Пора забыть про 7.7. для авторов есть журнал регистрации.
32. Владимир Полевик (pvvpvv) 9 12.09.09 23:44 Сейчас в теме
Я не хотел выкладывать. Это - элемент программмы. Я ее назвал - "Управлеие конфигурациями." Может быть, когда-нибуть - будет.
33. Maniac (Eugeneer) 12.09.09 23:52 Сейчас в теме
(32) дружище название неприкольное. назови лучше "Управление изменениями конфигураций программым методом" А в описании добавть, что основная фишка обработки это изменение конфигурации у заказчика без рук программиста и без удаленного доступа.
Тупо выслал обработку по почте, там щелкнули 1 кнопку - всё готово.
Не нужен ни удаленный доступ ни обмен файлами конфигурации (по сто метров).
34. Владимир Полевик (pvvpvv) 9 12.09.09 23:52 Сейчас в теме
При помощи обработки можно загонять "ково угодно" "куда угодно". (все)На этом этапе - "лишь бы было событие".
35. Владимир Полевик (pvvpvv) 9 12.09.09 23:55 Сейчас в теме
(33) Программа "Управление конфигурациями" отвечает не только за код.
36. Владимир Полевик (pvvpvv) 9 13.09.09 00:02 Сейчас в теме
Программа задумывалась для "Администраторов". Этот элемент? Пыль.
37. Артур Аюханов (artbear) 847 14.09.09 07:02 Сейчас в теме
Автор, название извини.
ИМХО как-то не очень связано универсальное название с конкретной доработкой в УТ :(
38. Артур Аюханов (artbear) 847 18.09.09 07:17 Сейчас в теме
39. Владимир Полевик (pvvpvv) 9 30.09.09 15:19 Сейчас в теме
(37) Слово "Пример" в названии подразумевает конкректное решение. Все обсуждение "после" касается доработки УТ, а не обработки. (хотя, прав я :evil: (исключительно по реализации ;) ). Рассуждения выложу. 8) ) Прошу извенить меня, всех, кому пока не ответил.