Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) Andrew189100, объединение конфигураций, что-же еще. Галки с умом расставляем, и все работает.
Если конкретно знаю что делаю в мелких масштабах (у меня есть одно место, где маленькая кофа), я тупо сохраняю себе cf-ник, меняю его, потом загружаю обратно целиком, проблем не было.
Если несколько разрабов, то - хранилище конфигураций.
Выбери свой вариант )))) В принципе, твой тоже имеет место быть. А проблемы с отчетами, - если все делал правильно, то проблем кроме засранного кэша пользователей, не должно быть.
Если конкретно знаю что делаю в мелких масштабах (у меня есть одно место, где маленькая кофа), я тупо сохраняю себе cf-ник, меняю его, потом загружаю обратно целиком, проблем не было.
Если несколько разрабов, то - хранилище конфигураций.
Выбери свой вариант )))) В принципе, твой тоже имеет место быть. А проблемы с отчетами, - если все делал правильно, то проблем кроме засранного кэша пользователей, не должно быть.
(2) Boneman, Спасибо. Как-то из головы вылетело про объединение... Хотя периодически обновляю измененную УНФ, через него)
(3) nickpugachev, 7 лет администрировал SAP R3. Там ,как раз и была система в варианте для больших. Разработка-Тест-Продакшен.
С 1С, относительно, недавно работаю. Написанная по просьбе утилита для печати товарных этикеток, начинает превращаться в учетную систему склада...
(3) nickpugachev, 7 лет администрировал SAP R3. Там ,как раз и была система в варианте для больших. Разработка-Тест-Продакшен.
С 1С, относительно, недавно работаю. Написанная по просьбе утилита для печати товарных этикеток, начинает превращаться в учетную систему склада...
(6) 32ops, Сложные разработки всегда выношу во внешние модули, очень часто алгоритмы на уровене пользователя. Может показаться, что есть проблемы с разработками, где много таблиц и реквизитов, но опять-же все можно грамотно продумать и сделать за 1 вечер :) а алгоритм потом неделю отлаживать. У меня 15 предприятий из них 5 заводов (от 500 до 1000 сотр-ов) и всегда разрабатываю только в рабочих базах. Поверь, есть ОЧЕНЬ сложные разработки.
(7) Я разрабатываю все на тестовой базе, затем производится тестирование с участием пользователей, заинтересованных в данном функционале, потом сравнение объединение. И этот способ я считаю нормальным. По твоей версии (если я правильно понял "Сложные разработки всегда выношу во внешние модули"), ты продумал изменения в структуре БД, применил, а потом из внешней обработки тестируешь новый функционал на рабочей базе, в которой работают 1000 человек прям во время работы?
(8) 32ops, нет, работает человек 20-30 - там выше у меня 1000 сотрудников, а не пользователей написано. Пользователей самое большое - 50 :). Тестирую обычно с 1, максимум 2 пользователями. Потом после первой проверки уже можно пускать в работу остальным.
Надо пример твоей разработки привести (может даже я такое или подобное уже где-то делал), так более предметно получится рассказать. Если интересно, конечно.
Надо пример твоей разработки привести (может даже я такое или подобное уже где-то делал), так более предметно получится рассказать. Если интересно, конечно.
(1) Andrew189100,
а)
Конфигурация - Загрузить конфигурацию из файла
(т.е.
п.1 делаешь копию рабочей, обновляешь её, например, на новый релиз, тестируешь, сохраняешь подготовленную конфигурацию в файл.
п.2 Снимаешь конфигурацию рабочей базы данных с поддержки
п.3 загружаешь подготовленную конфигурацию нового релиза)
б)
Конфигурация - Сравнить, объединить с конфигурацией из файла (применяется когда в более свежей конфигурации релиз не повышался)
в)
Использование хранилища конфигурации - актуально когда конфигурация на БСП (т.е. все новые редакции типовых, рабочая база в режиме клиент-сервер, база с доработками - файловая копия, т.к. не всякий сервер тянет все базы с агентом запущенным с ключом отладки. т.е. обновляем и тестируем баги и доработки на файловой копии, а затем переносим хранилище на рабочую базу в клиент-серверном варианте)
а)
Конфигурация - Загрузить конфигурацию из файла
(т.е.
п.1 делаешь копию рабочей, обновляешь её, например, на новый релиз, тестируешь, сохраняешь подготовленную конфигурацию в файл.
п.2 Снимаешь конфигурацию рабочей базы данных с поддержки
п.3 загружаешь подготовленную конфигурацию нового релиза)
б)
Конфигурация - Сравнить, объединить с конфигурацией из файла (применяется когда в более свежей конфигурации релиз не повышался)
в)
Использование хранилища конфигурации - актуально когда конфигурация на БСП (т.е. все новые редакции типовых, рабочая база в режиме клиент-сервер, база с доработками - файловая копия, т.к. не всякий сервер тянет все базы с агентом запущенным с ключом отладки. т.е. обновляем и тестируем баги и доработки на файловой копии, а затем переносим хранилище на рабочую базу в клиент-серверном варианте)
(1) Andrew189100, Думаю лучший вариант что вам предложили это хранилище и сравнение с хранилищем. Только хранилище иногда умеет умирать так что стоит и его бэкапить иногда.
Относительно доработок в сразу в продакшене. Ну не знаю динамические обновления без необходимости это очень глупый шаг. Только если сразу не можете написать весь код целиком. Тут все дело видимо в количестве клиентов. Я наверно слегка старомоден но все что выкладывается в рабочую должно быть протестировано и тестами покрыто. Ранят продакшен на несколько тысяч пользователей непозволительная роскошь из за меленького может сломаться большая система.
Относительно доработок в сразу в продакшене. Ну не знаю динамические обновления без необходимости это очень глупый шаг. Только если сразу не можете написать весь код целиком. Тут все дело видимо в количестве клиентов. Я наверно слегка старомоден но все что выкладывается в рабочую должно быть протестировано и тестами покрыто. Ранят продакшен на несколько тысяч пользователей непозволительная роскошь из за меленького может сломаться большая система.
Вариант для маленьких - сравнение и объединение конфигураций
вариант для побольше - хранилище для разработки и сравнение и объединение для рабочей
вариант для больших - dev (хранилище)->поставка->Stage->поставка->Production
вариант для побольше - хранилище для разработки и сравнение и объединение для рабочей
вариант для больших - dev (хранилище)->поставка->Stage->поставка->Production
(3) nickpugachev,
По варианту для маленьких.
Конфигурация Бухгалтерия 3.0 платформа 8.3.6.2332.
Обновился в копии с релиза 3.0.40.42 на 3.0.41.57. Выгрузил файл конфигурации и сравнением / объединением влил его в боевую.
После объединения база увидела что поднялся релиз, и сказала что обновилась.
Но теперь хочу еще раз обновиться, а при поиске обновления мне предлагается снова обновиться до 3.0.41.57.
Из любопытсва согласился обновить - выдает расхождение с текущей конфой только в моих изменениях.
Вот иллюстрации.
Как проге объяснить что текущий релиз 3.0.41.57?
По варианту для маленьких.
Конфигурация Бухгалтерия 3.0 платформа 8.3.6.2332.
Обновился в копии с релиза 3.0.40.42 на 3.0.41.57. Выгрузил файл конфигурации и сравнением / объединением влил его в боевую.
После объединения база увидела что поднялся релиз, и сказала что обновилась.
Но теперь хочу еще раз обновиться, а при поиске обновления мне предлагается снова обновиться до 3.0.41.57.
Из любопытсва согласился обновить - выдает расхождение с текущей конфой только в моих изменениях.
Вот иллюстрации.
Как проге объяснить что текущий релиз 3.0.41.57?
Прикрепленные файлы:
(55) vkozak, На Ваших картинках в первой - основная конфигурация, во второй - текущая конфигурация поставщика. Это две разные конфигурации, которые хранятся отдельно. И обновляются в общем случае отдельно. Объединением Вы обновили основную до 41.57, а текущая поставщика осталась старой 40.42
Хорошо, вот одна из последних задач для КА (немного упрощаю, иначе совсем в сторону уйдем).
Организация выполняет работы по ремонту техники. На данный момент в номенклатуре заведена одна услуга - ремонт техники.
Руководитель хочет видеть отчет в разрезах контрагентов, техники, сотрудников, видов работ. показатели - количество отработанных часов.
Контрагентам нужно печатать все печатные формы по старому одной услугой ремонт техники до перезаключения договора, после перезаключения - необходимо печатать по видам услуг, но не показывать сколько часов на нее затрачено, а 1шт. по такой-то цене. Договора будут перезаключаться в течение года. У Каждой услуги есть показатель - нормочасы, которые должны автоматически заполняться в документах при выборе услуги, но должна быть возможность изменять часы, затраченные на услугу. Услугу могут выполнять несколько сотрудников в разных пропорциях. Услуги могут оказываться себе (ремонт своей техники). Особые условия от руководителя - не меняй справочник номенклатуры, сделай так, чтобы услуга заносилась одной строкой, а в этой строке предусмотри, чтобы можно было выбирать несколько сотрудников и раздели поровну на них работу. А если не поровну, тогда можно несколькими строками. Может быть так, что клиенту выставили 10 часов, а сотрудники отработали 8, нужно предусмотреть. Виды работ можно менять определенным сотрудникам даже если дата запрета стоит, но только , чтобы количество нормо-часов выставленное клиенту не менялось. Про отчет не буду писать, т.к. это уже действительно можно сделать по ходу работы и на рабочей базе.
Критичные моменты для твоего способа разработки: 1) изменение структуры бд. 2) тестирование проведения документов по новым регистрам, 3) тестирование ввода реализации на основании заказа, 4) изменение механизма запрета по дате, 5) изменение форм документов, "несколько сотрудников в одной строке" - добавит сложности.
Организация выполняет работы по ремонту техники. На данный момент в номенклатуре заведена одна услуга - ремонт техники.
Руководитель хочет видеть отчет в разрезах контрагентов, техники, сотрудников, видов работ. показатели - количество отработанных часов.
Контрагентам нужно печатать все печатные формы по старому одной услугой ремонт техники до перезаключения договора, после перезаключения - необходимо печатать по видам услуг, но не показывать сколько часов на нее затрачено, а 1шт. по такой-то цене. Договора будут перезаключаться в течение года. У Каждой услуги есть показатель - нормочасы, которые должны автоматически заполняться в документах при выборе услуги, но должна быть возможность изменять часы, затраченные на услугу. Услугу могут выполнять несколько сотрудников в разных пропорциях. Услуги могут оказываться себе (ремонт своей техники). Особые условия от руководителя - не меняй справочник номенклатуры, сделай так, чтобы услуга заносилась одной строкой, а в этой строке предусмотри, чтобы можно было выбирать несколько сотрудников и раздели поровну на них работу. А если не поровну, тогда можно несколькими строками. Может быть так, что клиенту выставили 10 часов, а сотрудники отработали 8, нужно предусмотреть. Виды работ можно менять определенным сотрудникам даже если дата запрета стоит, но только , чтобы количество нормо-часов выставленное клиенту не менялось. Про отчет не буду писать, т.к. это уже действительно можно сделать по ходу работы и на рабочей базе.
Критичные моменты для твоего способа разработки: 1) изменение структуры бд. 2) тестирование проведения документов по новым регистрам, 3) тестирование ввода реализации на основании заказа, 4) изменение механизма запрета по дате, 5) изменение форм документов, "несколько сотрудников в одной строке" - добавит сложности.
(10) 32ops, выглядит очень просто: создать отдельный документ, в нем привязка ко всем необходимым самописным аналитиками и регистрам. Ну и ссылка на итоговый штатный документ реализации, который ни в коем случае не меняешь! (Тоже касается и номенклатуры). Нет никаких рисков, при проведении твоего документа и соот-но разработака в рабочей базе не критична.
Один момент - структуру этого документа и регистров можно заранее нарисовать в рабочей базе в рабочее время, а принять изменения вечером, когда никого нет в базе.
Справочники тоже максимально задействуй типовые, чтоб не городить лишнего.
Один момент - структуру этого документа и регистров можно заранее нарисовать в рабочей базе в рабочее время, а принять изменения вечером, когда никого нет в базе.
Справочники тоже максимально задействуй типовые, чтоб не городить лишнего.
(12) Если это будет отдельный документ - на основании него делать реализацию? реализовывать отдельный документ для корректировок этого документа? А если в реализации кроме услуг, есть товары? В заказе тоже нужны виды работ, оттуда печатные формы с видами работ должны печататься. На основании нового документа создавать заказ? А потом после корректировки заказа получим несоответствие. Да и вообще отдельный документ неудобно. Нужно добавлять ТЧ в заказ и реализацию. Но в общем я твой подход понял, поменьше менять типовые механизмы, делать все отдельными объектами. Подход правильный, но не всегда возможный. В общем спорить нам бесполезно, все равно при своих останемся, хочу обратить твое внимание только на небезопасность твоего подхода - потеряешь данные в реальной базе - спасибо не скажут.
(13) 32ops,
Именно так.
Это чтото новенькое.
Добавь их в свой. НАзови его наряд. А это материалы по наряду
Тебе все равно делать печатную форму заказу. Сделай ее лучше к своему документу
Запрети. Сделай программную синхронизацию при изменении. Нет ничего сложного в этом. Учись грамотную архитектуру кода писать.
Зачем?! Все делай в своем.
Молодец )
Вижу что бесполезно. У тебя какой опыт разработки? Мой подход работает более чем на 10 предприятиях которые у меня обслуживаются и поверь - всегда возможен. Хорошо что хотябы понимаешь, что он правильный. Конечно он более сложен в разработке, но мы ведь собрались тут не ради простоты.
Если это будет отдельный документ - на основании него делать реализацию?
Именно так.
реализовывать отдельный документ для корректировок этого документа?
Это чтото новенькое.
А если в реализации кроме услуг, есть товары?
Добавь их в свой. НАзови его наряд. А это материалы по наряду
В заказе тоже нужны виды работ, оттуда печатные формы с видами работ должны печататься. На основании нового документа создавать заказ?
Тебе все равно делать печатную форму заказу. Сделай ее лучше к своему документу
А потом после корректировки заказа получим несоответствие.
Запрети. Сделай программную синхронизацию при изменении. Нет ничего сложного в этом. Учись грамотную архитектуру кода писать.
Да и вообще отдельный документ неудобно. Нужно добавлять ТЧ в заказ и реализацию.
Зачем?! Все делай в своем.
Но в общем я твой подход понял, поменьше менять типовые механизмы, делать все отдельными объектами.
Молодец )
Подход правильный, но не всегда возможный. В общем спорить нам бесполезно, все равно при своих останемся, хочу обратить твое внимание только на небезопасность твоего подхода - потеряешь данные в реальной базе - спасибо не скажут.
Вижу что бесполезно. У тебя какой опыт разработки? Мой подход работает более чем на 10 предприятиях которые у меня обслуживаются и поверь - всегда возможен. Хорошо что хотябы понимаешь, что он правильный. Конечно он более сложен в разработке, но мы ведь собрались тут не ради простоты.
(14) Итог.
1)Мы отказались от заказа покупателя в пользу нашего документа. Это означает, что наш документ должен делать все движения по регистрам вместо заказа (т.е. как минимум мы изменяем регистраторы у группы типовых регистров, ну и надо бы проверять всю конфу в запросах, как бы это боком не вылезло).
2)Про программную синхронизацию - она ведь должна быть двухсторонняя , т.е. либо не давать менять документ реализация в части наших видов работ, либо предпринимать дополнительные действия при изменении, т.е. в типовый код все равно мы залезем.
3)Опыт разработки не аргумент в нашем споре. "Мой подход работает более чем на 10 предприятиях которые у меня обслуживаются и поверь - всегда возможен" - не поверю. Тут мало кто верит на слово, иначе бы мы были уже не программисты.
4) Не описал как ты будешь обходить механизм даты запрета, оно и понятно, придется лезть в типовые модули, а ты же не можешь признать, что твой подход не всегда возможен.
1)Мы отказались от заказа покупателя в пользу нашего документа. Это означает, что наш документ должен делать все движения по регистрам вместо заказа (т.е. как минимум мы изменяем регистраторы у группы типовых регистров, ну и надо бы проверять всю конфу в запросах, как бы это боком не вылезло).
2)Про программную синхронизацию - она ведь должна быть двухсторонняя , т.е. либо не давать менять документ реализация в части наших видов работ, либо предпринимать дополнительные действия при изменении, т.е. в типовый код все равно мы залезем.
3)Опыт разработки не аргумент в нашем споре. "Мой подход работает более чем на 10 предприятиях которые у меня обслуживаются и поверь - всегда возможен" - не поверю. Тут мало кто верит на слово, иначе бы мы были уже не программисты.
4) Не описал как ты будешь обходить механизм даты запрета, оно и понятно, придется лезть в типовые модули, а ты же не можешь признать, что твой подход не всегда возможен.
(15) 32ops,
Мой подход работает более чем на 10 предприятиях которые у меня обслуживаются и поверь - всегда возможен. Хорошо что хотябы понимаешь, что он правильный.
Никогда, вернее вот так: НИКОГДА не слушай вот такие вот "речи" про разработку в "боевой" базе, никогда ничего не разрабатывай и не тестируй на "боевой" базе, только на копии... и будет тебе счастье... Даже если ты сейчас работаешь с небольшими и крохотными базами, в которых даже бывает, что "в базе никого нет" - всё равно не стоит вырабатывать в себе дурные привычки...
(19) ИНТЕГРА, наверное, это очень круто, быть настолько опытным, чтобы сразу в голове представить работу внедряемых новшеств от и до, и вчистовую, безошибочно код вживлять, чтобы это сразу работало, на живой базе.
Мне до такого уровня, еще расти и расти, приходится, сначала все на тестовых базах испытывать, прежде чем пускать в дело.
Есть еще куда развиваться, да ))
Мне до такого уровня, еще расти и расти, приходится, сначала все на тестовых базах испытывать, прежде чем пускать в дело.
Есть еще куда развиваться, да ))
(15) 32ops,
Ты вообще все не так понимаешь. Мы живем в разных вселенных :) любые мои подсказки представляешь абсолютно не верно. Просто дам комментарии еще раз на твои предложния.
1. В дополнению к заказу, а не вместо.
2. Не двухсторонняя, а только от самописного документа к типовому. Типовой блокируется. Перечитай мое прошлое сообщение об этом.
3. Ты просто на секунду поверь. Один профессиональный программист более чем в 10 раз производительней малоопытного. Вдумайся в эту цифру, это не мои расчеты. Погугли. Вообще я считаю программистов на общеобразовательной базе у нас не готовят (а может и не только у нас). Я и не знал что на этом форуме еще и куча лжецов, и никто ни кому не верит. Он все меньше меня привлекает. И, кстати, я не только программист.
4. Какие даты запрета?! У тебя свои регистры. Если ты в закрытом периоде попытаешься создать типовой - то система должна тебя опракинуть. Икаких обходов. Все модули на замках отсаются. Если интнресно я мог бы расписать твое решение до мелочей, но смысла не вижу, не оценишь.
Ты вообще все не так понимаешь. Мы живем в разных вселенных :) любые мои подсказки представляешь абсолютно не верно. Просто дам комментарии еще раз на твои предложния.
1. В дополнению к заказу, а не вместо.
2. Не двухсторонняя, а только от самописного документа к типовому. Типовой блокируется. Перечитай мое прошлое сообщение об этом.
3. Ты просто на секунду поверь. Один профессиональный программист более чем в 10 раз производительней малоопытного. Вдумайся в эту цифру, это не мои расчеты. Погугли. Вообще я считаю программистов на общеобразовательной базе у нас не готовят (а может и не только у нас). Я и не знал что на этом форуме еще и куча лжецов, и никто ни кому не верит. Он все меньше меня привлекает. И, кстати, я не только программист.
4. Какие даты запрета?! У тебя свои регистры. Если ты в закрытом периоде попытаешься создать типовой - то система должна тебя опракинуть. Икаких обходов. Все модули на замках отсаются. Если интнресно я мог бы расписать твое решение до мелочей, но смысла не вижу, не оценишь.
(18) "Не двухсторонняя, а только от самописного документа к типовому. Типовой блокируется" Типовой блокировать полностью нельзя, это очевидно. Делаю вывод, что ты имеешь ввиду "блокировать" документ, который создан "самописным нарядом". т.е. я уже в реализации не смогу сделать вместе и продажу товаров и оказание услуг, которые пришли из наряда, а мне нужно оформлять все одним документом. Как быть в этом случае?
"Какие даты запрета?! У тебя свои регистры." - хорошо, дугой пример. У продажников доступ 1 день, для того, чтобы они не смогли проводить документы неоперативно (дату запрета устанавливает регламент ночью). Продажники формируют заказы несколько дней. Например, 10.10.15 Провели заказ с частью товара. А 11.10.15 нужно добавить еще товары в этот заказ (такие уж требования - все в одном заказе, корректировки использовать не наотрез не хотят). Но доступа к заказу от 10.10.15 уже нет. Нужна кнопка, которая (после определенных проверок) перепроведет документ сегодняшней датой. Как оставить все под замком?
"профессиональный программист более чем в 10 раз производительней малоопытного." - я понял кто в какую категорию попал, правильно не скромничай.
"Я и не знал что на этом форуме еще и куча лжецов, и никто ни кому не верит" - ну вот только не надо переигрывать. Ну ясен пень если я взял обработку с инфостарта, я обязан проверить ее работоспособность, если мне предложили способ решения задачи, я поищу и другие, мне всегда казалось, что так действует основная часть программистов.
"Какие даты запрета?! У тебя свои регистры." - хорошо, дугой пример. У продажников доступ 1 день, для того, чтобы они не смогли проводить документы неоперативно (дату запрета устанавливает регламент ночью). Продажники формируют заказы несколько дней. Например, 10.10.15 Провели заказ с частью товара. А 11.10.15 нужно добавить еще товары в этот заказ (такие уж требования - все в одном заказе, корректировки использовать не наотрез не хотят). Но доступа к заказу от 10.10.15 уже нет. Нужна кнопка, которая (после определенных проверок) перепроведет документ сегодняшней датой. Как оставить все под замком?
"профессиональный программист более чем в 10 раз производительней малоопытного." - я понял кто в какую категорию попал, правильно не скромничай.
"Я и не знал что на этом форуме еще и куча лжецов, и никто ни кому не верит" - ну вот только не надо переигрывать. Ну ясен пень если я взял обработку с инфостарта, я обязан проверить ее работоспособность, если мне предложили способ решения задачи, я поищу и другие, мне всегда казалось, что так действует основная часть программистов.
(18) Да и насчет "мои подсказки" Подсказки - это оказание кому-то помощи. Дело то было так "Надо пример твоей разработки привести (может даже я такое или подобное уже где-то делал), так более предметно получится рассказать." Т.е. в нашем диалоге не помощь, а обсуждение подходов. Я привел пример, мы его обсудили, кто как решает задачи. Не нужно манипулировать.
Полистал я данную ветку, и брошу свои 5 копеек.
По мне, так приятнее и удобнее работать через хранилище - будь то хоть маленькая база, хоть большая, хоть мелкая доработка, хоть крупная.
Насчет разработки сразу в рабочей базе - скорость внедрения разработок, имхо, не стоит потенциальных рисков грохнуть важные данные.
ИНТЕГРА, с его, несомненно, колоссальным опытом, может обойтись и без бэкапов, тем более, если в базе каких-то 50 пользователей и 1000 сотрудников...
Добавлю.
Хотелось бы посмотреть на обработки/отчеты/доработки уважаемого ИНТЕГРА вживую.
Надо же знать, к чему стремиться :)
По мне, так приятнее и удобнее работать через хранилище - будь то хоть маленькая база, хоть большая, хоть мелкая доработка, хоть крупная.
Насчет разработки сразу в рабочей базе - скорость внедрения разработок, имхо, не стоит потенциальных рисков грохнуть важные данные.
ИНТЕГРА, с его, несомненно, колоссальным опытом, может обойтись и без бэкапов, тем более, если в базе каких-то 50 пользователей и 1000 сотрудников...
Добавлю.
Хотелось бы посмотреть на обработки/отчеты/доработки уважаемого ИНТЕГРА вживую.
Надо же знать, к чему стремиться :)
Доброго времени суток !
На мой взгляд доработки типовых конфигураций должны максимально (по возможности) не затрагивать типовую конфигурацию. Тогда и проблем с обновлением меньше и с переносом доработок из "разработки" в "Боевую" не возникает. На платформе 8 все для этого есть, подписка на событие, куча общих модулей и. т.д. Есть конечно проблемы которые подписками не решить, приходится все таки править типовые модули. Сам работаю когда как удобно или в "копии" потом переношу или сразу в "боевой". Свои изменения переношу объединением конф.
А по поводу изменения типовых конфигурации я хочу сказать, что задачи клиентов необходимо решать все таки с минимальным изменением типового функционала.
На мой взгляд доработки типовых конфигураций должны максимально (по возможности) не затрагивать типовую конфигурацию. Тогда и проблем с обновлением меньше и с переносом доработок из "разработки" в "Боевую" не возникает. На платформе 8 все для этого есть, подписка на событие, куча общих модулей и. т.д. Есть конечно проблемы которые подписками не решить, приходится все таки править типовые модули. Сам работаю когда как удобно или в "копии" потом переношу или сразу в "боевой". Свои изменения переношу объединением конф.
А по поводу изменения типовых конфигурации я хочу сказать, что задачи клиентов необходимо решать все таки с минимальным изменением типового функционала.
(27) Dr_Medved, в 10ку попал! Согласитесь, что при таком подходе риски похерить типовое минимальны. Чего тогда бояться не пойму. Думаю тут вопрос в подходе к доработкам более существеннен, чем их перенос и лежит вне данного топика.
(26) akita, интересно какую роль и какие конкретно задачи решались именно тобой при автоматизации обозначенного числа заводов.
(22) Xershi, конечно sql, другого не проповедуем. Файловые как правило мелочовка, их и за проекты не считаю :)
(23) axelerleo, могу пример привести. Есть сеть АЗС. Клиент выкупает вагон топлива и забирает его с разных заправок в течении месяца и более, заправляясь каждый день. Этот вагон принадлежит после оплаты клиенту и числится на забалансе. Оформляют продажу и отдают накладные по одному складу. При каждой заправке оформляется расх.ордер. Однако в фоне система формирует 2 перемещения топлива (одно по БУ, другое по УУ), чтобы отрегуллировать остаток на забалансе и уменьшить собственное топливо на этот объём на соответствующей АЗС. Задача не такая тривиальная, как в примере у 32ops, но обходится без изменения типовых механизмов. С блокировкой "фоновых" перемещений от редактирования. Показать эту доработку не просто, тк это комплекс подписок на событий.
(26) akita, интересно какую роль и какие конкретно задачи решались именно тобой при автоматизации обозначенного числа заводов.
(22) Xershi, конечно sql, другого не проповедуем. Файловые как правило мелочовка, их и за проекты не считаю :)
(23) axelerleo, могу пример привести. Есть сеть АЗС. Клиент выкупает вагон топлива и забирает его с разных заправок в течении месяца и более, заправляясь каждый день. Этот вагон принадлежит после оплаты клиенту и числится на забалансе. Оформляют продажу и отдают накладные по одному складу. При каждой заправке оформляется расх.ордер. Однако в фоне система формирует 2 перемещения топлива (одно по БУ, другое по УУ), чтобы отрегуллировать остаток на забалансе и уменьшить собственное топливо на этот объём на соответствующей АЗС. Задача не такая тривиальная, как в примере у 32ops, но обходится без изменения типовых механизмов. С блокировкой "фоновых" перемещений от редактирования. Показать эту доработку не просто, тк это комплекс подписок на событий.
(29) ИНТЕГРА,
Когда Вы от ДОработок перейдёте хотя бы к РАЗработкам - вот тогда всё встанет на свои места :о) Дерзайте...
интересно какую роль и какие конкретно задачи решались именно тобой при автоматизации обозначенного числа заводов.
Для обозначенной первой "десятки"? На определённом жизненном этапе "не помнить всех с кем втречался" или "не помнить всё над чем работал" это скорее "естественное положение вещей" или даже осознанная необходимость, чем то, о чём можно сожалеть... Поэтому разработка и тестирование в боевой базе, это как переход на красный свет: в определенное время суток и на определенной дороге это может "прокатить" и даже не один раз... но нужно понимать, что открыто советовать "переходите на красный, ничего страшного в этом нет, я на десяти улицах постоянно перехожу на красный и жив здоров!" - это перебор. И не нужно переводить разговор в русло "необходимости минимизации изменений в типовом функционале" - я говорил абсолютно не об этом :о)
Думаю тут вопрос в подходе к доработкам более существеннен, чем их перенос и лежит вне данного топика
Когда Вы от ДОработок перейдёте хотя бы к РАЗработкам - вот тогда всё встанет на свои места :о) Дерзайте...
(30) akita,
Боюсь не Вам меня судить, ибо судя по Вашему ответу роль в проектах у Вас эпизодическая. Я свои проекты делаю сам. И прошу поверить, они не маленькие. Некоторые из них стоят на мониторинге у 1С (не маленькие заводы).
Еще не плохо было бы услышать в чем разница для Вас между этими ДО... и РАЗ... Вы разработали собственную УПП с нуля, что бы так смело говорить о моём опыте?
ДОработок перейдёте хотя бы к РАЗработкам
Боюсь не Вам меня судить, ибо судя по Вашему ответу роль в проектах у Вас эпизодическая. Я свои проекты делаю сам. И прошу поверить, они не маленькие. Некоторые из них стоят на мониторинге у 1С (не маленькие заводы).
Еще не плохо было бы услышать в чем разница для Вас между этими ДО... и РАЗ... Вы разработали собственную УПП с нуля, что бы так смело говорить о моём опыте?
(36) ИНТЕГРА, внедрение. Т.е. поставить коробку? Ну какая разница сколько сотрудников на заводе. Запустил обработку, а она и миллион пройдет и хоть бы что.
Если высказываете мнение, которое явно противоречит здравой логике, то оговаривайте границы, где это было бы уместно. Пока мы только поняли, что вам везло при разработке архитектуры ПО. Но как сложится дальше ситуация, думаю мы и так это знаем. Тогда возможно и задумаетесь, что лучше делать правильно, чтобы потом ни дай бог косяк не огрести.
Если высказываете мнение, которое явно противоречит здравой логике, то оговаривайте границы, где это было бы уместно. Пока мы только поняли, что вам везло при разработке архитектуры ПО. Но как сложится дальше ситуация, думаю мы и так это знаем. Тогда возможно и задумаетесь, что лучше делать правильно, чтобы потом ни дай бог косяк не огрести.
(39) Xershi, видно, что ты полный ноль во внедрении, тк любой тебе скажет - чем больше предприятие, тем больше ньюансов при внедрении. Коробки ставить это не наша тема. Дичайшие доработки и настройки возникают на пост-советских предприятиях с бабушками. Тебе это не понять и зря в теме пытаешься умничать.
PS: везет уже более 15 лет внедренческого опыта. Как думаешь, достаточно, чтобы выработать определенные правила и рекомендации?
PS: везет уже более 15 лет внедренческого опыта. Как думаешь, достаточно, чтобы выработать определенные правила и рекомендации?
(40) ИНТЕГРА, а никто про нюансы и не говорит. Почитав тебя так любой говнокодер начнет работать как ты и что будет?
Я же все проговорил, но бить в грудь что мне везет, а скорее наоборот. Ты четко знаешь, что обновляешь. А затем подчищаешь следы, которые могут положить базу. Вот и выходит, что ты дартаньян, а молодые разработчики, ну вы поняли.
но еще раз поторяю не забывайте, что нужно оговаривать границы применимости. А у вас выходит, что при любом раскладе у вас никогда база не ляжет. Ляжет, если допустите ошибку. А люди как известно не роботы!
Я же все проговорил, но бить в грудь что мне везет, а скорее наоборот. Ты четко знаешь, что обновляешь. А затем подчищаешь следы, которые могут положить базу. Вот и выходит, что ты дартаньян, а молодые разработчики, ну вы поняли.
но еще раз поторяю не забывайте, что нужно оговаривать границы применимости. А у вас выходит, что при любом раскладе у вас никогда база не ляжет. Ляжет, если допустите ошибку. А люди как известно не роботы!
(44) Xershi, говнокодер не потянет, он очень осторожен, тк не знает где его код выстрелит. Тут я говорил уже - важен правильный подход к доработакам. Они должны быть продуманы заранее. Код вылизан, вплодь до назнаний переменных и тп... Вообщем ознакомьтесь со стандартами разработки на Си++, там много полезного, а у 1С вы такого не найдете.
(41) nickpugachev, поверь, разработки там столько, что хватит некоторым на пол жизни. Ты видел проект внедрения УПП на предприятии (например на 1000сотров) без доработок когда-нибудь? Можешь хотябы себе такое представить? Задай им этот вопрос. А если некому задать, то лучше слушай, а не спорь.
(45) ИНТЕГРА, Судя по точному знанию количества сотрудников - внедряли зарплатный блок?
На внедрении ЗУП доработки обычно минимальны. И ОЧЕНЬ аккуратные. Ну и отчеты. Их много. И все. Огромное количество времени на них занимает согласование/настройка/обучение. Из-за этого они сжирают много времени.
А так - да, УПП дорабатывается всегда. Только вот давно я уже не меряю проекты количеством сотрудников на предприятии. Все как-то количеством пользователей... А то ЗУП с двумя десятками пользователей может и 5-10 тысяч сотрудников отсчитывать. А может и обычная УТ дохнуть от 100 пользователей и кучи регламентов.
На внедрении ЗУП доработки обычно минимальны. И ОЧЕНЬ аккуратные. Ну и отчеты. Их много. И все. Огромное количество времени на них занимает согласование/настройка/обучение. Из-за этого они сжирают много времени.
А так - да, УПП дорабатывается всегда. Только вот давно я уже не меряю проекты количеством сотрудников на предприятии. Все как-то количеством пользователей... А то ЗУП с двумя десятками пользователей может и 5-10 тысяч сотрудников отсчитывать. А может и обычная УТ дохнуть от 100 пользователей и кучи регламентов.
(31) ИНТЕГРА,
Мой вам совет, не защищать на форумах 1С такие подходы к разработке как:
- динамическое обновление в продуктиве с работающими пользователями
- разработка и тестирование нового функционала в продуктиве.
Мы верим вашим успехам на "поле боя" огромных организаций, но ваши подходы противоречат стандартным подходам разработки на платформе 1С 8 и вы врядли найдете себе тут соратников :) Сэкономьте свои нервы и наши животы) Успехов!)
Мой вам совет, не защищать на форумах 1С такие подходы к разработке как:
- динамическое обновление в продуктиве с работающими пользователями
- разработка и тестирование нового функционала в продуктиве.
Мы верим вашим успехам на "поле боя" огромных организаций, но ваши подходы противоречат стандартным подходам разработки на платформе 1С 8 и вы врядли найдете себе тут соратников :) Сэкономьте свои нервы и наши животы) Успехов!)
(31) ИНТЕГРА,
И вообще, предостерегал от "вредных привычек" я не Вас, а Вашего собеседника. И не сразу, а когда уровень "советов" перешагнул "уровень моей внутренней терпимости", который, уверяю Вас, достаточно высок :о)
А вам я еще раз напишу, как и в предыдущем посте: "Дерзайте!", никоим образом не собирался "учить" Вас "развлекаться на пост-советских предприятиях с бабушками"...
Я свои проекты делаю сам
15-20 лет назад и я свои проекты делал сам на заводиках по 1000-2000 сотрудников :о) Сейчас проекты "выросли" и сам я их делать уже не могу, кодингом занимается штат программистов... На каком основании Вы делаете вывод судя по Вашему ответу роль в проектах у Вас эпизодическая
мне не понятно, да и не интересно. Из-за того, что я с пеной у рта не стал расписывать "всё и вся", очень многое из которого закрыто соглашением о неразглашении как минимум?
Боюсь не Вам меня судить
Я и не сужу, я просто цитирую Ваши слова... В цитатку ткнуть?
Еще не плохо было бы услышать в чем разница для Вас между этими ДО... и РАЗ...
Чтобы опять в следующем посте прочитать очередное Ваше "не так понятое" "Судя по Вашему ответу..." - уж не, увольте :о)
И вообще, предостерегал от "вредных привычек" я не Вас, а Вашего собеседника. И не сразу, а когда уровень "советов" перешагнул "уровень моей внутренней терпимости", который, уверяю Вас, достаточно высок :о)
А вам я еще раз напишу, как и в предыдущем посте: "Дерзайте!", никоим образом не собирался "учить" Вас "развлекаться на пост-советских предприятиях с бабушками"...
(51) akita,
По поводу цитаты - это я Вашу цитату привел, думал поймете о чем речь, но уже не важно.
вопросов нет, если на Ваших предприятиях численность подходит к 5000 там думаю подход изменится (надеюсь лгать это не про Вас, а то мне на этом форуме некоторые заявляли, что не верят тому что тут пишут). Скажу откровенно с такими не работал. Но я не думаю что ТС из таких внедренцев.
У меня товарищ работает на проекте, где 600 пользователей работающих одновременно. Я к тому времени уволился с того предприятия и ушел в самостоятельное плаванье. Кое какие вещи, в реализации откровенно корявые там допущены, проект делает дочка 1С. Естественно в боевой там никто не кодит, но тут уровень обсуждения не тот, чтобы брать в расчет такие проекты.
По поводу цитаты - это я Вашу цитату привел, думал поймете о чем речь, но уже не важно.
вопросов нет, если на Ваших предприятиях численность подходит к 5000 там думаю подход изменится (надеюсь лгать это не про Вас, а то мне на этом форуме некоторые заявляли, что не верят тому что тут пишут). Скажу откровенно с такими не работал. Но я не думаю что ТС из таких внедренцев.
У меня товарищ работает на проекте, где 600 пользователей работающих одновременно. Я к тому времени уволился с того предприятия и ушел в самостоятельное плаванье. Кое какие вещи, в реализации откровенно корявые там допущены, проект делает дочка 1С. Естественно в боевой там никто не кодит, но тут уровень обсуждения не тот, чтобы брать в расчет такие проекты.
(53) ИНТЕГРА,
Я всё больше удивляюсь Вашим выводам) С одной стороны Вы пишите, что "в боевой там никто не кодит", потом пишите "но тут уровень обсуждения не тот" Собственно и ТУТ в боевой НИКТО не кодит только Вы тут к этому ПОЧЕМУ-то и ЗАЧЕМ-ТО призываете :о) И при чём тут вообще уровень обсуждений? Уровень обсуждений определяется озвученной и обсуждаемой проблемой Если многие темы не выходят за рамки СП это не говорит о том, что "тут" только люди, которые даже СП не читали :о) Я больше чем уверен, если сейчас крикнуть в теме: "РебятыКрутыеПрограммисты, с огромными познаниями в 1с и с++, достигшие огромных результатов во внедрении архисложнейших проектов на предприятиях вселенского масштаба - ОТЗОВИТЕСЬ" - вряд ли вообще кто-то ответит, и это абсолютно понятно почему,
И вывод тут напрашивается только один: "скромнее надо быть...".
P.S. Конечно после этого Вы опять напишете про то, какой Вы д'Атраньян, а мы все... но мне это будет уже не интересно и читать я это скорее всего уже не стану...
Естественно в боевой там никто не кодит, но тут уровень обсуждения не тот, чтобы брать в расчет такие проекты
Я всё больше удивляюсь Вашим выводам) С одной стороны Вы пишите, что "в боевой там никто не кодит", потом пишите "но тут уровень обсуждения не тот" Собственно и ТУТ в боевой НИКТО не кодит только Вы тут к этому ПОЧЕМУ-то и ЗАЧЕМ-ТО призываете :о) И при чём тут вообще уровень обсуждений? Уровень обсуждений определяется озвученной и обсуждаемой проблемой Если многие темы не выходят за рамки СП это не говорит о том, что "тут" только люди, которые даже СП не читали :о) Я больше чем уверен, если сейчас крикнуть в теме: "РебятыКрутыеПрограммисты, с огромными познаниями в 1с и с++, достигшие огромных результатов во внедрении архисложнейших проектов на предприятиях вселенского масштаба - ОТЗОВИТЕСЬ" - вряд ли вообще кто-то ответит, и это абсолютно понятно почему,
НО!
Это в той же мере никак не говорит о том, что "тут" таких не может быть, и это тоже абсолютно понятно почему))) И Ваши замечания про "трёх программистов на всём форуме" прекрасно Вас характеризуют как "большого знатока человеческой психологии". И также абсолютно понятно почему никто и не обижается на такие "высеры", мало того, их просто пропускают мимо ушей. И также не вызывает никаких сомнений какое именно отношение будет к Вам у "тутошних" обитателей после подобных откровений... И не подумайте, что это будет какое-то ненавистное или злое отношение... оно просто будет никакое...
И вывод тут напрашивается только один: "скромнее надо быть...".
P.S. Конечно после этого Вы опять напишете про то, какой Вы д'Атраньян, а мы все... но мне это будет уже не интересно и читать я это скорее всего уже не стану...
(54) akita, а тут собственно и отвечать нечего. В принципе согласен, пусть все пишут как им удобно, будем считать, что я выразил свое мнение и меня услышали :)
И не лень тебе писать такие психологические тексты ни о чем? Лучше бы о проекте каком своем рассказал.
И не лень тебе писать такие психологические тексты ни о чем? Лучше бы о проекте каком своем рассказал.
(68) ИНТЕГРА,
Лучше бы о проекте каком своем рассказал.
Это еще зачем??? Заниматься самолюбованием? Писать сколько где было сотров, расчетчиков и бухов? Это вообще зачем? Это и не показатель ни успешного внедрения ни эффективности разработки. Тут у нас что? "Клуб анонимных программистов разработчиков" которые плачутся друг другу в жилетку? Нет. Или тут песочница в детском садике, где детишки меряются сами знаете чем? Тоже нет))) Тогда зачем? Кидать бестолковые понты? Мне это не нужно))) Расписывать подробности стандартного внедрения стандартного функционала на мелких предприятиях? Это зачем??? Это даже не понты, а ежедневная обыденность. Может еще рассказать как каждый день одеваюсь и что кушаю на обед? Помнишь "вчерашние" мелкие проекты? Да молодец! Даже расписываешь их тут зачем-то, вдвойне молодец! Обиделся, что не все тут такие разговорчивые "нарциссы"? Ну это не моя проблема))) Не понимаешь, что "не помнить всё над чем работал"
и не помнить "вчерашний" проект это совсем разные вещи? Это тоже проблема не моя)) Выразил своё мнение и неприятно, что "закидали калошами"??? Ну так привыкай) Это не " на пост-советских предприятиях с бабушками" лапшу развешивать)))
(72) akita,
Обмен опытом. Именно для этого форум и задумывался. Наверно просто некоторым рассказать нечего, голые понты без реальных дел...
(73) ну давай расскажи как ты обновляешь сначала тестовую, а потом рабочую. Очень интересно почитать такие мемуары )))
Вот тут:
Ты ОЧЕНЬ ошибаешься.
Ты вот это читал, уник?
Если ты у нас такой опытный, то почему сразу не увидел логической ошибки? Уже сам наверно догадался или опыта не хватает?
Это еще зачем??? Заниматься самолюбованием?Обмен опытом. Именно для этого форум и задумывался. Наверно просто некоторым рассказать нечего, голые понты без реальных дел...
(73) ну давай расскажи как ты обновляешь сначала тестовую, а потом рабочую. Очень интересно почитать такие мемуары )))
Вот тут:
суть твоей проблемы от того рабочая база или копия не изменитсяТы ОЧЕНЬ ошибаешься.
Ты вот это читал, уник?
Обновился в копии с релиза 3.0.40.42 на 3.0.41.57. Выгрузил файл конфигурации и сравнением / объединением влил его в боевуюЕсли ты у нас такой опытный, то почему сразу не увидел логической ошибки? Уже сам наверно догадался или опыта не хватает?
(74) ИНТЕГРА,
Суть его проблемы в том, что копию он обновил, а рабочую объединил. Или для тебя это одно и тоже? Забористые у тебя грибочки однако)))))
Уже даже не смешно вчитываться в твой бред, расписывать прописные истины... Не пора тебе уже завязывать??? Не надоело еще? Опытом я с тобой обмениваться не собираюсь, мне кажется это сразу было понятно). Тем более если рассказ про "трёх расчетчиц бабушек пенсионерок" у тебя приравнивается к обмену опытом, то увольте, мне такой "обмен" не нужен, своё время дороже... И о моих "реальных делах", как ты говоришь, тебе знать абсолютно незачем и что ты думаешь об их наличии мне глубоко параллельно))) А так, как говорится "жжошь, пеши исчо!"...
(73) ну давай расскажи как ты обновляешь сначала тестовую, а потом рабочую. Очень интересно почитать такие мемуары )))
В (73) от меня ни слова нет про обновление тестовой, а потом рабочей))). Ты какие грибочки там покуриваешь???
Вот тут:
суть твоей проблемы от того рабочая база или копия не изменится
Ты ОЧЕНЬ ошибаешься.
суть твоей проблемы от того рабочая база или копия не изменится
Ты ОЧЕНЬ ошибаешься.
Суть его проблемы в том, что копию он обновил, а рабочую объединил. Или для тебя это одно и тоже? Забористые у тебя грибочки однако)))))
Уже даже не смешно вчитываться в твой бред, расписывать прописные истины... Не пора тебе уже завязывать??? Не надоело еще? Опытом я с тобой обмениваться не собираюсь, мне кажется это сразу было понятно). Тем более если рассказ про "трёх расчетчиц бабушек пенсионерок" у тебя приравнивается к обмену опытом, то увольте, мне такой "обмен" не нужен, своё время дороже... И о моих "реальных делах", как ты говоришь, тебе знать абсолютно незачем и что ты думаешь об их наличии мне глубоко параллельно))) А так, как говорится "жжошь, пеши исчо!"...
(74. ИНТЕГРА) Согласен вот с этим "....Обмен опытом. Именно для этого форум и задумывался. ...". и обновление конфигурации таким способом не правильно
"... Обновился в копии с релиза 3.0.40.42 на 3.0.41.57. Выгрузил файл конфигурации и сравнением / объединением влил его в боевую .... " во всем остальном не согласен.
(72)akita, Полностью согласен, в данный момент пост выглядит соревнованием "у кого головной убор больше". Не бывает маленьких баз, любая база это в первую очередь труд людей которые наполняли её информацией и потеря одного часа работы, в случае сбоя, при обновлении, это как минимум не профессионально.
1. По этому копия для разработки необходима.
2. Перед обновлением(как конфигурации, так и платформы) копию снимать обязательно.
Если база встретилась, все время "он-лайн", тут подходов может быть много от составления регламента на предприятии до использования хранилища конфигурации, а то может быть самым лучшим способом будет снятие боевой с поддержки, и вливать изменения и дополнения объединением. На мой взгляд способ очень плохой, но ситуации бывают разные. Опять так если заказчик согласен, и понимает все риски такого способа, то тогда в добрый путь.
Самый лучший, на мой взгляд, способ это РИБ все клиенты работают в подчиненном узле, а я в главном.
"+"
Если нужно что то внедрить я на своем узле показываю новый функционал, заказчик принимает его, и отправляю его в рабочую.
(У ИНТЕГРА мне кажется никогда не бывает случаев когда Заказали одно, а потом передумали и решили сделать почти полностью другое, с полным переписыванием начального ТЗ)
Обновление тоже проходит без проблем.
При таком способе решается задача резервного копирования. (побочный эффект).
Так как я работаю на отдельном сервере, влияние на пользователей "0".
Я могу в любой момент "влить себе" свежие данные.
При работе с WEB сервисами сразу ловим не читаемые символы XML.
Так же при обновлении обновляются все конфигурации которые есть в базе.
"-"
В базе появляется дополнительный, но необходимый "мусор" в качестве содержимого регистра "соответствие объектом для выгрузки".
И еще несколько регистров(не помню точно название).
Медленные компьютеры "мимо".
Если идет активная работа в основной базе, то свежие данные заливать каждый день, иначе обновлять можно потом очень долго но и эти минусы можно "автоматизировать". Главное что бы клиент был доволен.
"... Обновился в копии с релиза 3.0.40.42 на 3.0.41.57. Выгрузил файл конфигурации и сравнением / объединением влил его в боевую .... " во всем остальном не согласен.
(72)akita, Полностью согласен, в данный момент пост выглядит соревнованием "у кого головной убор больше". Не бывает маленьких баз, любая база это в первую очередь труд людей которые наполняли её информацией и потеря одного часа работы, в случае сбоя, при обновлении, это как минимум не профессионально.
1. По этому копия для разработки необходима.
2. Перед обновлением(как конфигурации, так и платформы) копию снимать обязательно.
Если база встретилась, все время "он-лайн", тут подходов может быть много от составления регламента на предприятии до использования хранилища конфигурации, а то может быть самым лучшим способом будет снятие боевой с поддержки, и вливать изменения и дополнения объединением. На мой взгляд способ очень плохой, но ситуации бывают разные. Опять так если заказчик согласен, и понимает все риски такого способа, то тогда в добрый путь.
Самый лучший, на мой взгляд, способ это РИБ все клиенты работают в подчиненном узле, а я в главном.
"+"
Если нужно что то внедрить я на своем узле показываю новый функционал, заказчик принимает его, и отправляю его в рабочую.
(У ИНТЕГРА мне кажется никогда не бывает случаев когда Заказали одно, а потом передумали и решили сделать почти полностью другое, с полным переписыванием начального ТЗ)
Обновление тоже проходит без проблем.
При таком способе решается задача резервного копирования. (побочный эффект).
Так как я работаю на отдельном сервере, влияние на пользователей "0".
Я могу в любой момент "влить себе" свежие данные.
При работе с WEB сервисами сразу ловим не читаемые символы XML.
Так же при обновлении обновляются все конфигурации которые есть в базе.
"-"
В базе появляется дополнительный, но необходимый "мусор" в качестве содержимого регистра "соответствие объектом для выгрузки".
И еще несколько регистров(не помню точно название).
Медленные компьютеры "мимо".
Если идет активная работа в основной базе, то свежие данные заливать каждый день, иначе обновлять можно потом очень долго но и эти минусы можно "автоматизировать". Главное что бы клиент был доволен.
(76) Dr_Medved, Разработка в переферийке интересный вариант, но интересен скорей чисто академически. На практике громоздко. Были мысли использовать такой подход. У меня есть среди клиентов оператор связи (тел/интернет) и охранное агенство. Так вот, доработки у них как ни странно, очень похожие. Порой мне хочется иметь у них одинаковые конфигурации, тк очень часто бывает - то что просят одни через какое-то время просят другие. Боюсь я никогда не рискну их посадить на периферийные узлы, и поставить у себя центральную :)
Тут я бы лучше послушал как это у тебя бывало, чтобы было с чем сравнить (если конечно не боишься как рассказать о своем опыте, как некоторые ;) ). Иначе начнем о разные ситуации обобщать и получится как с akita - разговор ни о чем )
(У ИНТЕГРА мне кажется никогда не бывает случаев когда Заказали одно, а потом передумали и решили сделать почти полностью другое, с полным переписыванием начального ТЗ)
Тут я бы лучше послушал как это у тебя бывало, чтобы было с чем сравнить (если конечно не боишься как рассказать о своем опыте, как некоторые ;) ). Иначе начнем о разные ситуации обобщать и получится как с akita - разговор ни о чем )
(78) ИНТЕГРА, И так делюсь опытом что бы разговор был со смыслом. Автоматизация небольшой туристической базы ООО "Х", Используемая конфигурация
1С Отель. У клиента, на другом объекте есть кастомно разработанная конфигурация, в этой конфигурации есть интерфейс администратора гостиницы к которому сотрудники уже привыкли и переучиваться не хотят. После долгих переговоров заказчик все таки настаивает на доработке 1С Отель, в части этого интерфейса (клиент всегда прав, приступаю к работе). Суть интерфейса графическое отображения номерного фонда, далее "Шахматка" (ось X - даты, ось Y это номера с точностью до места, пересечение координат показывает занятость номера\места), с возможностью управлять заселением, бронирование, уборкой номера, отображения минимальной информации о номере, фильтры, и т.д., и еще одно ограничение использовать только встроенные объекты конфигурации, ни каких внешних компонент. (у Заказчика был негативный опыт, дальнейшей поддержки такого рода дополнений) все ТЗ описывать думаю не надо. В первоначальном ТЗ точность шахматки оговаривается пол дня, т.е. клетка "шахматки" делится на две части, все что в первой полвине дня первая часть, все что во второй половине дня вторая часть. Изготавливаю интерфейс, в тестовой базе(! :) ), показываю заказчику, заказчик смотрит, говорит все хорошо, принимает работу, переношу в боевую. Все вроде хорошо. Звонок на следующее утро, Заказчик - а давайте сделаем точность "шахматки" до 1 часа (т.е. одна клетка шахматки делится на 24 части), пользователи уже работают, база работает круглосуточно, останавливать базу нельзя. Составляем новое ТЗ, переделываю "шахматку", показываю её Заказчику, все хорошо, подписываем акт приема-передачи, переносим в рабочую, все вроде ок. Утро - звонок, заказчик - необходимо внести дополнительный фильтр "категории объектов", при чем для каждого пользователя он должен настраиваться согласно полномочиям пользователя. Переделываем ТЗ, показываю, акт, перенос в боевую, и так еще месяц, добавляю, убираю, расширяю разработанный функционал. И все это проделывать надо сразу "по живому", на боевой базе? Я не такой крутой программист, в процессе разработки, тоже допускаю ошибки, поэтому в тестовой базе отлаживать код проще, и заказчик по ходу дела, вносит свои коррективы.
Складывается впечатление, что у Вас там полный "коммунизм", или Вы счастливый обладатель "аналитического отдела" с экстрасенсорной специализацией в части чтения мыслей Заказчиков, и Вы загодя знаете что, у Вас закажут, и в каком объеме.
1С Отель. У клиента, на другом объекте есть кастомно разработанная конфигурация, в этой конфигурации есть интерфейс администратора гостиницы к которому сотрудники уже привыкли и переучиваться не хотят. После долгих переговоров заказчик все таки настаивает на доработке 1С Отель, в части этого интерфейса (клиент всегда прав, приступаю к работе). Суть интерфейса графическое отображения номерного фонда, далее "Шахматка" (ось X - даты, ось Y это номера с точностью до места, пересечение координат показывает занятость номера\места), с возможностью управлять заселением, бронирование, уборкой номера, отображения минимальной информации о номере, фильтры, и т.д., и еще одно ограничение использовать только встроенные объекты конфигурации, ни каких внешних компонент. (у Заказчика был негативный опыт, дальнейшей поддержки такого рода дополнений) все ТЗ описывать думаю не надо. В первоначальном ТЗ точность шахматки оговаривается пол дня, т.е. клетка "шахматки" делится на две части, все что в первой полвине дня первая часть, все что во второй половине дня вторая часть. Изготавливаю интерфейс, в тестовой базе(! :) ), показываю заказчику, заказчик смотрит, говорит все хорошо, принимает работу, переношу в боевую. Все вроде хорошо. Звонок на следующее утро, Заказчик - а давайте сделаем точность "шахматки" до 1 часа (т.е. одна клетка шахматки делится на 24 части), пользователи уже работают, база работает круглосуточно, останавливать базу нельзя. Составляем новое ТЗ, переделываю "шахматку", показываю её Заказчику, все хорошо, подписываем акт приема-передачи, переносим в рабочую, все вроде ок. Утро - звонок, заказчик - необходимо внести дополнительный фильтр "категории объектов", при чем для каждого пользователя он должен настраиваться согласно полномочиям пользователя. Переделываем ТЗ, показываю, акт, перенос в боевую, и так еще месяц, добавляю, убираю, расширяю разработанный функционал. И все это проделывать надо сразу "по живому", на боевой базе? Я не такой крутой программист, в процессе разработки, тоже допускаю ошибки, поэтому в тестовой базе отлаживать код проще, и заказчик по ходу дела, вносит свои коррективы.
Складывается впечатление, что у Вас там полный "коммунизм", или Вы счастливый обладатель "аналитического отдела" с экстрасенсорной специализацией в части чтения мыслей Заказчиков, и Вы загодя знаете что, у Вас закажут, и в каком объеме.
(81) Dr_Medved, Спасибо за подробности. Поделюсь опытом разработки в практически аналогичной задаче. У меня: Ось У-бетономешалки (миксеры), ось Х-время с получасовыми интервалами. Смысл тот-же. Управлеие занятостью - двойной клик по ячейке: открывается форма записи периодического регистра сведений.
Создаю РС сразу в рабочей базе УПП. Структуру продумываю заранее (пара дополнительных ресурсов втавилось еще течение недели при общении с заказчиком). Все, Больше в структуру не не лезем!
Теперь сама шахматка. Она ессно на СКД. Дискретность интервала задается константой зашитой в коде (не нужно было для этого иметь аналитический отдел. Ясно, что заказчик сразу не отгадает как ему удобно будет, менялась она раза 4 по мере общения. В итоге=10 минут). Все фильтры штатно на скд: отчет встроен в метаданные, хотя можно было сделать внешним и тогда даже динамическое обновление не надо было бы делать.
Немного о реализации: В пост-обработке вывода отчета делаю программное объединение ячеек с одинаковым текстом по горизонтали. Если интересно могу рассказать подробности некоторых моментов реализации.
Можно было не говорить, что помимо смесей у них производство железобетона и прочей жести ведется в базе. Постоянно-работающих Пользователей около 30. Режим с 8:00-17:00. Все "принятия изменений" конфигурации делаются вечером, бэкаб базы ежечасный ессно на ms sql.
Создаю РС сразу в рабочей базе УПП. Структуру продумываю заранее (пара дополнительных ресурсов втавилось еще течение недели при общении с заказчиком). Все, Больше в структуру не не лезем!
Теперь сама шахматка. Она ессно на СКД. Дискретность интервала задается константой зашитой в коде (не нужно было для этого иметь аналитический отдел. Ясно, что заказчик сразу не отгадает как ему удобно будет, менялась она раза 4 по мере общения. В итоге=10 минут). Все фильтры штатно на скд: отчет встроен в метаданные, хотя можно было сделать внешним и тогда даже динамическое обновление не надо было бы делать.
Немного о реализации: В пост-обработке вывода отчета делаю программное объединение ячеек с одинаковым текстом по горизонтали. Если интересно могу рассказать подробности некоторых моментов реализации.
Можно было не говорить, что помимо смесей у них производство железобетона и прочей жести ведется в базе. Постоянно-работающих Пользователей около 30. Режим с 8:00-17:00. Все "принятия изменений" конфигурации делаются вечером, бэкаб базы ежечасный ессно на ms sql.
(82) ИНТЕГРА, вот так и надо сразу говорить - пользователей у меня в базах мало, режим работы офигенный, при проблемах с кэшем можно тупо подскочить к пользователю, а в случае воплей по поводу выскакивающего окна с просьбой перезапустить клиента - просто послать пользователя.
С такими базами - не хорошо, конечно, но очень аккуратно и много напрягая извилину, можно и наживую что-то отработать.
С такими базами - не хорошо, конечно, но очень аккуратно и много напрягая извилину, можно и наживую что-то отработать.
(90) ИНТЕГРА,
Изначально говорил, что предприятия у меня до 5000 сотрудников. Обычно на производстве по моим оценкам менее 5% из них работают в 1С
Отсюда я сделал вывод, что максимальное количество пользователей было 250, видимо вас не беспокоят по таким пустякам, типо форма перестала открываться, или отчет не формируется. И сколько помню, помимо всего сказанного выше, большим камнем в разработке сразу в боевой является оповещалка другим пользователям, что конфигурация изменена и просьбой перезайти, и если изменения не были приняты, то эта оповещалка будет отображаться все время, если конечно каждый пользователь не запустит базу под определенным ключом.
(82) ИНТЕГРА, Режим работы действительно не плохой, после 17.00 можно делать что угодно. СКД не использую так как с моим интерфейсом работает 10 человек и обновление отображение должно быть быстрым, но это все уже технические подробности. Внешняя обработка в моем случае тоже не подходит так как это есть "рабочий стол" администратора. В остальном если есть резервная копия, постоянная тогда соглашусь, с (83) nickpugachev. Но мой путь это работа в копии.
А к вопросу, кэша ( (83) nickpugachev )то ошибка потока может возникнуть и при простом обновлении из копии. Проблему кэша решал зачисткой его в .bat файле при запуске 1С.
А к вопросу, кэша ( (83) nickpugachev )то ошибка потока может возникнуть и при простом обновлении из копии. Проблему кэша решал зачисткой его в .bat файле при запуске 1С.
(88) ИНТЕГРА, если стоимость часа простоя базы измеряется минимум шестизначными суммами, а время восстановления из бэкапа часами - "уметь работать" в рабочей базе вредно.
И разработка разная бывает. Попробуйте полностью переработать проведение амортизации ОС на рабочей базе :)
И разработка разная бывает. Попробуйте полностью переработать проведение амортизации ОС на рабочей базе :)
(98) nickpugachev, Ну еще расскажи, что, если атомным реактором 1С управляет, то пол страны нае##тся. Конечно ситуации разные.
Очень интересно было бы послушать в чем заключалась доработка. Ведь можно из-за песчинки половину конфигурации переворотить, а можно минимальными изменениями получить быстрый и качественный результат. Я сторонник подхода по второму варианту. Когда надо переворотить половину конфигурации - рекомендую взять паузу и еще раз подумать как этого избежать. И решение найдется.
И разработка разная бывает. Попробуйте полностью переработать проведение амортизации ОС на рабочей базе :)
Очень интересно было бы послушать в чем заключалась доработка. Ведь можно из-за песчинки половину конфигурации переворотить, а можно минимальными изменениями получить быстрый и качественный результат. Я сторонник подхода по второму варианту. Когда надо переворотить половину конфигурации - рекомендую взять паузу и еще раз подумать как этого избежать. И решение найдется.
(108) ИНТЕГРА, дабы пользователи не создавали лишней нагрузки на техподдержку, им обычно закрывается возможность запустить что-либо кроме нужных программ. Батники закрываются в первую очередь, потому что пользователь с правом запуска батника - потенциальный геморрой в квадрате.
К тому же очень много продуктивных сред делается на удаленных рабочих столах с использованием RemoteApp либо Citrix, и пользователь в принципе не имеет доступа к запуску чего-либо на сервере кроме опубликованного приложения.
Пойдите поработайте в компанию с большой ИТ, пользователей в 200-300 и больше. Вам там самим прав не дадут на лишние действия. Ну или в финансовую контору типа НПФ или банка.
К тому же очень много продуктивных сред делается на удаленных рабочих столах с использованием RemoteApp либо Citrix, и пользователь в принципе не имеет доступа к запуску чего-либо на сервере кроме опубликованного приложения.
Пойдите поработайте в компанию с большой ИТ, пользователей в 200-300 и больше. Вам там самим прав не дадут на лишние действия. Ну или в финансовую контору типа НПФ или банка.
(85) nickpugachev, Да, с формами проблема при "динамике", но все таки решаемая.
(88) ИНТЕГРА, Отпугнула утечка памяти, при использование СКД. У меня "шахматка" обновляется раз в 15 сек. После работы от 15 до 23 часов, начало тормозить решение, чем больше работает тем медленней обновляется. Провел исследование оказалось исполняемый файл клиента 1С весит порядка 700 мб, и поэтому тормозит от СКД отказался, конечно есть еще один момент база у клиента PostgresSQL, смущает это факт, но способ я нашел как исправить ситуацию, работает все это уже 1 год.
(88) ИНТЕГРА, Отпугнула утечка памяти, при использование СКД. У меня "шахматка" обновляется раз в 15 сек. После работы от 15 до 23 часов, начало тормозить решение, чем больше работает тем медленней обновляется. Провел исследование оказалось исполняемый файл клиента 1С весит порядка 700 мб, и поэтому тормозит от СКД отказался, конечно есть еще один момент база у клиента PostgresSQL, смущает это факт, но способ я нашел как исправить ситуацию, работает все это уже 1 год.
(95), А случайно временных таблиц не используете в запросе? Была у нас такая же утечка, решили путем явного уничтожения временных таблиц в запросе, и очисткой вспомогательных переменных после окончания формирования отчета.
Разумеется, у Вас ситуация может совсем другая быть.
Разумеется, у Вас ситуация может совсем другая быть.
(96) axelerleo, нет ситуация другая, формировали чистое поле "шахматки" ( (81) Dr_Medved ), а затем накладывали данные, при обновлении отчета, что - бы не тратить время на отрисовку "шахматки" в поле табличного документа выводили сразу чистую "шахматку" и отрисовали данные. Так вот при использовании СКД, (сбор и вывод только данных) происходила описанная выше ситуация ( (95)Dr_Medved )., но спасибо за совет учту на будущее.
(99) nickpugachev, да, согласен, все зависит от уровня использования базы, если это "ларек" на ЕНВД тогда требования одни, а если это компания с он-лайн мониторингом ситуации по грузоперевозками и минута простоя базы стоит порядка 30 - 40 тыс. руб. тогда ни о каких динамических обновлениях и речи быть не может. Но и еще может быть просто у Топа настроение плохое. :)))
Как я уже писал мой путь, это отладка в КОПИИ. И еще хочу сказать не бывает в программировании не решаемых проблем, бывает мало платят за их решения и тогда они становятся нерешаемыми :)
(99) nickpugachev, да, согласен, все зависит от уровня использования базы, если это "ларек" на ЕНВД тогда требования одни, а если это компания с он-лайн мониторингом ситуации по грузоперевозками и минута простоя базы стоит порядка 30 - 40 тыс. руб. тогда ни о каких динамических обновлениях и речи быть не может. Но и еще может быть просто у Топа настроение плохое. :)))
Как я уже писал мой путь, это отладка в КОПИИ. И еще хочу сказать не бывает в программировании не решаемых проблем, бывает мало платят за их решения и тогда они становятся нерешаемыми :)
(53) ИНТЕГРА, любопытно как у вас проходят внедрения на таких крупных заводах, ведь по большему счету тут даже не дорабатывать надо, а в большем случае обучать, и это ведь не один человек, а целая вереница отделов, если впрямь взять к примеру только зарплатную часть, у меня на предприятии 3 Расчетчика, 3 Кадровика, 2 табельщика. А сама реализация внедрения проходит жесткие этапы согласования, мне кажется только на отчеты о проделанной работе можно очень много времени убить. Вот сколько пользователей у вас в базах работает, при численности предприятия в 2000 человек?
(61) karpik666, Максимально подключаем силы сотрудников. В том числе отдел автоматизации, где есть админы. По пользователям на том проекте было 3 расчетчика, 4 сотрудника ОТиЗ, 1 табельщик, ну и собственно главбух. Обучать обычно требуется только ведущего сотрудника отдела, он остальным раздает задания (такие вещи у меня всегда решаются организационно).
Ко всем задачам подход индивидуальный, например если ОТиЗ делали специфические расчеты доплат в экселе, то зачем отбирать у них этот инструмент и переписыванием заниматься? - они просто загружают эти результаты в ТЧ разового начисления.
После расчета все ложится в огромный отчет на СКД. Он показывает им какая часть сотрудников в отпуске была, какая на больничных, кто в коммандировке... все это с суммами и с разрезами по ФОТ.
Структура предприятия тоже очень интересная оказалась в том проекте - ОТиЗ и расчетчики (как потом выяснилось) используют разные структуры предприятия (у них около 15 подразделений). Тут на помощь пришли два справочника подразделений ЗУПы и красиво легло на тот гигантский отчет СКД.
Проекту уже более 5 лет, и все как ни удивительно для akita прекрасно помню. Коммерческой информации здесь тоже не вижу. Так что больше походит на отмазки непонятные сами знаете кого.
Ко всем задачам подход индивидуальный, например если ОТиЗ делали специфические расчеты доплат в экселе, то зачем отбирать у них этот инструмент и переписыванием заниматься? - они просто загружают эти результаты в ТЧ разового начисления.
После расчета все ложится в огромный отчет на СКД. Он показывает им какая часть сотрудников в отпуске была, какая на больничных, кто в коммандировке... все это с суммами и с разрезами по ФОТ.
Структура предприятия тоже очень интересная оказалась в том проекте - ОТиЗ и расчетчики (как потом выяснилось) используют разные структуры предприятия (у них около 15 подразделений). Тут на помощь пришли два справочника подразделений ЗУПы и красиво легло на тот гигантский отчет СКД.
Проекту уже более 5 лет, и все как ни удивительно для akita прекрасно помню. Коммерческой информации здесь тоже не вижу. Так что больше походит на отмазки непонятные сами знаете кого.
На счет писать код сразу в живой базе... Ну написал а обновлять как, если при этом чуть ли не ежесуточно сидят дофига пользователей и обновлять надо не динамически, несколько раз при тестировании выгонять всех пользователей!? Даже если динамически обновлять, почитайте на форуме как часто после этого базам капец приходит. Для меня так вариант 1, это работать на тестовой (желательно через хранилище, как для маленьких баз так и для больших, если это не разовый клиент). Для автора топика работать в тестовой и накатывать через сравнение-объединение.
Читаю я ветку и диву даюсь - насколько же товарища Интегру зацепили остальные товарищи!
Интегра, при всем уважении, ваша точка зрения подходит скорее под исключение, нежели под правило.
Это как решать систему нелинейных уравнений в уме. Допустим, вы научились. Но это же не повод всех заставлять выбрасывать ручки с тетрадями просто потому, что вы уже 15 лет считаете в уме.
А насчет внедрений и печальных последствий - Вам, должно быть, несказанно везло, что Вы ни разу не повреждали (стирали, удаляли, неверно модифицировали) важные данные для каких-нибудь собственников бизнеса родом из лихих 90-х.
Интегра, при всем уважении, ваша точка зрения подходит скорее под исключение, нежели под правило.
Это как решать систему нелинейных уравнений в уме. Допустим, вы научились. Но это же не повод всех заставлять выбрасывать ручки с тетрадями просто потому, что вы уже 15 лет считаете в уме.
А насчет внедрений и печальных последствий - Вам, должно быть, несказанно везло, что Вы ни разу не повреждали (стирали, удаляли, неверно модифицировали) важные данные для каких-нибудь собственников бизнеса родом из лихих 90-х.
(56) vkozak, При обновлении сравниваешь-объединяешь с новым релизом, снимаешь все галки. Обновится только конфигурация поставщика.
Иногда приходится так делать, если нужно обновить подряд несколько релизов. Я обычно обновляю только конфигурации поставщика, и лишь на последнем релизе делаю полноценное обновление через сравнение/объединение.
Иногда приходится так делать, если нужно обновить подряд несколько релизов. Я обычно обновляю только конфигурации поставщика, и лишь на последнем релизе делаю полноценное обновление через сравнение/объединение.
(57) axelerleo, Вариант создавать файл поставки и делать не сравнение - объединение, а обновление конфигурации через Поддержка - Обновить конфигурацию с выбором своего файла обновления никто не рассматривает вообще, или я это пропустил? ИМХО - сравнение / объединение - это "клюшечный" подход....
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот