Наш филиал в Германии закупает товары и продает их российскому юридическому лицу. Использовавшаяся в нем система Tsenit позволяла вести учет только на уровне финансовых данных: кто, кому и сколько должен денег, когда прошла покупка или продажа и т.д. Учет товара и логистические задачи средствами Tsenit было выполнять невозможно, для решения этих задач приходилось использовать дополнительные инструменты, что отрицательно влияло на скорость и надежность всей системы. Данные в результате были разбросаны по нескольким базам.
К тому же немецкое юрлицо должно сдавать отчетность, платить налоги и проходить аудиторские проверки — а с существовавшими системами учета решать подобные задачи было непросто.
Чтобы понять, почему в Tsenit были сделаны те или иные финансовые проводки, и ответить на простые вопросы налоговых служб или аудиторов, приходилось вручную лопатить огромные объемы данных в Excel и обращаться в отдел логистики.
В какой-то момент было решено объединить бухгалтерию и финансы с логистикой в единый контур в рамках одной ERP-системы филиала. В качестве основного программного обеспечения была выбрана Microsoft Dynamics 365 — бывшая Dynamics AX, или еще проще — Axapta. Российских клиентов, использующих облачное решение этой системы, почти нет (если быть точнее — мы стали вторыми), но для наших целей оно подходило лучше всего.
Сроки, бюджет и вера в светлое будущее
У нас были жесткие ограничения по срокам: запуск подобной системы в середине финансового года требует переноса всего набора исторических данных, что стало бы неподъемной задачей, ведь в старой системе товарный учет фактически отсутствовал и велся в электронных таблицах. Зато в начале отчетного периода достаточно перенести только балансы. Таким образом, запуск необходимо было произвести либо 1 января 2019 года, либо отложить его еще на год. Связанные с торговлей и складской логистикой процессы не особенно сложные, и нам казалось, что проблем со сроками не возникнет.
Кроме сроков был еще вопрос бюджета: разворачивать и обслуживать в Германии собственную ИТ-инфраструктуру и покупать корпоративные программные лицензии слишком дорого в пересчете на одного пользователя.
Поскольку в немецких бизнес-процессах участвует не более 20 человек, мы остановились на облачном решении Dynamics 365. Для небольших удаленных филиалов схема SaaS оптимальна, она позволяет получить все необходимое ПО и среды разработки, чтобы начать внедрение сразу после подписания договора с провайдером.
Политика лицензирования Microsoft Dynamics 365 предельно проста и предполагает фиксированную стоимость за одну пользовательскую лицензию в месяц, при этом количество пользователей можно увеличивать или уменьшать. Это стало еще одним аргументом за выбор именно этого программного продукта.
Подводные камни
Главная проблема лежала вне технической плоскости: мы не знали всех требований европейского законодательства к ведению учета в подобных системах. Microsoft Dynamics 365 охватывает огромное количество бизнес-процессов; выпускаются так называемые пакеты локализации, которые позволяют гибко настраивать решение под специфику законодательства конкретной страны. Если российскую версию команда разработки давно изучила, то с версией для Германии мы никогда не сталкивались. Настройка такого решения силами собственной команды стала бы трудновыполнимой задачей.
У немецкого менеджмента были опасения, что российская сторона не справится с поставленной задачей из-за отсутствия опыта и знаний в локальном налоговом и бухгалтерском учете. В итоге выбрали золотую середину и привлекли внешний консалтинг. Он должен был закрыть связанные с европейскими законодательными требованиями пробелы, обеспечить аудит миграции из предыдущей финансовой системы, проанализировать описания бизнес-процессов, оптимизировать их и подогнать под будущее решение с максимальным использованием стандартной функциональности. При необходимости доделок их планировалось выполнить, постепенно погружая российскую команду в разработку.
Начало внедрения и перенос данных
По-умолчанию мы получили права на три среды: BUILD — для сборки созданного разными разработчиками кода в одно приложение, SAT (Standard Acceptance Testing) — для проведения приемочного пользовательского тестирования, а также PROD — для эксплуатации. Помимо этого для каждого разработчика в Azure развернуты виртуальные машины dev-box. Вся инфраструктура управляется и мониторится через единый портал — Lifecycle services, а особенность процесса кастомизации заключается в том, что любые доработки попадают в среду PROD только через SAT.
Благодаря тому, что в качестве новой системы был выбран Microsoft Dynamics 365, перенос данных удалось осуществить сравнительно несложно, с помощью доступных из коробки Data packages. В Dynamics 365 есть тесная связь с продуктами Microsoft, в том числе и с Excel: для пользователя это выглядело как электронная таблица с подключением к сервисам Dynamics 365 через ODATA. С помощью расширения Excel пользователи публиковали данные напрямую в систему. Немецкая сторона готовила шаблоны, отмечая в них обязательные для заполнения столбцы. Пользователи эти шаблоны заполняли, а консультанты контролировали процесс импорта.
Среди прочего из старой системы учета консалтеры перенесли информацию о поставщиках и клиентах, а также балансы по счетам главной книги. Прямой перенос всех данных по товарам потребовал бы значительного времени и усилий, и мы постарались решить эту задачу более эффективным способом. Была реализована интеграция новой системы учета немецкого филиала с основной российской системой, в которой находятся мастер-данные по товарам. Физических остатков в Германии на конец года у нас не было, и в итоге потребовалось перенести из старой системы только справочную информацию, необходимую для дальнейшего товародвижения. Таким образом удалось обойтись без переноса всех исторических данных по товарам, что сохранило время.
Полуаутсорсинг: подключение российской команды
Начав внедрение в июне 2018 года, мы рассчитывали решить все задачи до новогодних праздников, но помимо естественных в таких проектах языковых проблем появились трудности с коммуникацией. Консалтеры из Германии долго отвечали на запросы. Работник не может работать без перерыва более 6 часов подряд. После окончания работы он должен иметь минимум 11 часов свободного от работы времени. А когда специалист занимается другим клиентом, его нельзя ни о чем спрашивать. Такой формальный подход повлиял на сроки. В какой-то момент подрядчик предложил к новому году запустить только финансовый учет, который и так работал в старой системе. Нас это не устроило. С 2013 года мы самостоятельно внедряем Axapta в Lamoda, а в 2016 году полностью перевели на нее весь бухгалтерский учет из 1С. Процессы в России куда более сложные, поэтому мы знали: проект можно завершить в установленные сроки.
Мы решили привлечь российскую команду, забрав у коллег из Германии всю кастомизацию и разработку функциональности системы. Фактически мы оставили внешнему подрядчику только консалтинг, постановку задач и функциональный дизайн. Они говорили нам, что нужно сделать, мы это делали, а потом они тестировали и принимали результаты. Скорость внедрения возросла, но вскоре и такая организация рабочего процесса потребовала пересмотра: немецкий консультант по финансам ушел в отпуск на три недели. Для проекта этот срок стал критичным, основные задачи у нас были связаны именно с финансами, налогами и тому подобными вещами. Пришлось взять на себя и эту часть, в итоге наши специалисты разобрались с европейским налоговым законодательством не сильно хуже, чем внешние.
Плюс постоянно возникали какие-то нестандартные задачи. Благодаря глубокому погружению основной российской команды в разработку, решить их удавалось сравнительно быстро. Кроме того, решения изначально разрабатывались с учётом знаний о всех системах и процессах, используемых в нашей компании.
Одна из таких задач — интеграция нового облачного окружения с существующей российской ERP-системой. В ней уже была реализована связанная с работой закупщиков функциональность, и мы не хотели дублировать код, чтобы не усложнять его поддержку. В итоге заказы на покупку товаров у иностранных поставщиков создаются в российской ERP и потом переносятся в немецкое облако.
В процессе внедрения российская команда освоила полностью новый для нас подход к разработке и новый инструментарий. Раньше мы использовали собственную IDE для Axapta, но здесь перешли на Visual Studio и Azure DevOps. Во время реализации проекта менялись версии ПО, а наши специалисты познали все прелести параллельной разработки для облачных сред — в техническом плане это было весьма интересно.
SureStep vs Agile: проблемы запуска
Коллеги из Германии работали по методологии Microsoft SureStep. Это негибкий подход, который ближе к классическому «водопаду». Он предполагает на каждом этапе документирование всего, подготовку функциональных и технических дизайнов, тщательное тестирование с выпуском протоколов, запись процессов в какую-нибудь систему моделирования и т.д. С запросом на такую документацию коллеги обратились к нам за месяц до запуска. Новая ERP-система к тому моменту уже более-менее функционировала. Предполагая запустить ее за полгода, мы выбрали более гибкие методики разработки: ежедневные стендапы, обсуждение задач и еженедельные релизы. Для ведения документации использовали Work items в Azure DevOps, там же отражали ход проекта и подтверждали результаты тестирования.
Поскольку система облачная, финальное решение о ее выходе в продакшен принимала компания Microsoft, все контакты с которой осуществляли наши подрядчики. Они, в свою очередь, оказались не готовы посылать заявку без всей необходимой с точки зрения методологии SureStep документации. В итоге своевременный запуск проекта оказался под угрозой.
Мы решили связаться с вендором самостоятельно и получили одобрение на выход в продакшен, после чего спокойно и планомерно дорабатывали функциональность системы своими силами. Немецкие специалисты помогли нам перенести настройки из тестовой среды в продуктовую. После этого они настраивали бухучет и устраняли недочеты, если у нас возникали какие-то замечания.
Испытание в бою
Благодаря своевременному привлечению собственной команды нам удалось уложиться в сроки и запустить систему 1 января 2019 года, как и планировалось изначально.
Новая учетная система объединила финансовую часть и логистику, мы уже сдали через нее квартальную отчетность в Германии. Перед этим нам удалось провести т.н. закрытие месяца без значительного ущерба по срокам. При запуске такого класса систем задержки неизбежны, но в январе мы опоздали на три дня, а в феврале — всего на один. Данные из системы пока собираем вручную, сейчас российская команда разработки занимается автоматизацией отчетности. Проблемы в основном связаны с человеческим фактором: сотрудникам сложно выполнять новые для них процедуры, и какие-то шероховатости обязательно вылезают.
Сейчас мы имеем прозрачную картину по товарам на уровне отдельных складских номеров (SKU) и данные об остатках на промежуточных европейских складах. Ряд задач до конца закрыть не получилось: есть трудности с интеграцией с немецким банком и еще ряд мелких проблем, на своевременное решение которых ресурсов внутренней команды не хватило — изначально предполагалось, что этот фронт работ закроет подрядчик. В основном все сводится только к отсутствию должного уровня автоматизации и некоторому увеличению объема ручной работы у конечных пользователей. Сейчас мы постепенно закрываем бреши силами своей команды и с помощью нового партнера с отделением в России.
Бонусом того, что над проектом работали наши разработчики, стало ещё и то, что сразу на этапе внедрения были выполнены доработки, улучшающие функциональность системы.
Российская команда разработала автоматическое определение налога по заказам на покупку и продажу. По умолчанию система требует ручной установки бухгалтером налоговой схемы при обработке накладной и разноске проводок. При этом нужно учитывать страну отгрузки, страну регистрации поставщика, кто забирает груз (получатель или поставщик), кто отправляет груз в РФ (немецкое или российское юр. лицо), везут ли груз напрямую от поставщика в Россию или груз проходит консолидацию в Европе. Всех этих тонкостей по каждой поставке у бухгалтера нет. Мы полностью автоматизировали процесс в системе таким образом, что необходимые исходные параметры вводит ответственный логист. Дальше система на основании созданных настроек сама определяет налоговую схему и необходимые бухгалтерские проводки. Все данные автоматически консолидируются в необходимые статистические отчеты для Германии и налоговую декларацию. Таким образом, обязанности лучше распределены между специалистами, скорость и надежность работы возрастают.
Итоги
Изначально мы рассчитывали на то, что большая часть работ ляжет на подрядчика, а в результате все ключевые блоки сделали силами собственной разработки. Обычно запуск ERP занимает от 1 года, нам же удалось запуститься за 6 месяцев с момента инициации проекта, из которых активная разработка длилась всего в 3 месяца.
В итоге мы получили уникальный опыт, которым и решили поделиться. Сотрудничество со знающими местные условия иностранными подрядчиками имеет практический смысл, но ждать от них чудес не стоит. Если у вас имеется собственная сильная команда, на аутсорсинг стоит выносить только консалтинг и постановку задач, а также тестирование.
Это не конец нашей истории. Новый вызов связан с внедрением в России единой национальной системы маркировки товаров. Законодатели перенесли сроки ее запуска на 2020 год, но мы хотим уже с июля маркировать каждую пару обуви уникальным штрих-кодом до прохождения товаром таможни. Помимо этого всегда есть связанные с оптимизацией производительности задачи. Ну и прочих идей и планов у нас предостаточно. При их реализации мы теперь будем больше полагаться на свои силы, для чего сначала придется немного «растолстеть».
Комментарии (39)
CrushBy
25.07.2019 15:00И еще маленький вопрос:
Кроме сроков был еще вопрос бюджета: разворачивать и обслуживать в Германии собственную ИТ-инфраструктуру и покупать корпоративные программные лицензии слишком дорого в пересчете на одного пользователя.
А почему нельзя было просто запустить это все на российской инфраструктуре? Пинг до Германии где-то 50мс, разве этого недостаточно?
sgots Автор
25.07.2019 17:02Тут акцент все-таки больше не на инфраструктуру в Германии, а на инфраструктуру как таковую. Даже в России нужно было выделять серверные мощности под виртуальные сервера. Если выделять отдельное железо, то есть риск не утилизировать его полностью. Если использовать виртуализацию на текущем — все равно рано или поздно нужно будет расширяться. Посчитали наши объемы (по сути нагрузку на систему), отправили этот чеклист вендору и получили 7 виртуальных машин только под продакшн. Кроме этого еще приближенный к продуктивному environment для пользовательского тестирования, и чуть более сжатый вариант под сборку приложения. И это все без учета DRP. С учетом небольшого количества пользователей, всего 20 лицензий, вариант с облачным решением подошел идеально.
CrushBy
25.07.2019 17:06Извините, но 7 виртуальных машин под 20 пользователей? А можно поинтересоваться какие характеристики этих виртуальных машин?
sgots Автор
25.07.2019 20:21Облачная версия Dynamics — это чистый SaaS, у клиента нет доступа к продуктивной среде совсем. Даже средств посмотреть сайзинг виртуальных машин нету. Этим управляет вендор на основе показателей производительности и заявленных требований клиента.
Тут нету прямой зависимости между пользователями и нагрузкой. 20 пользователей может нагенерировать достаточно данных для фоновой обработки, как в нашем случае. Если чуть более конкретно, то сайзинг окружения считается, исходя из запускаемых процессов (какая функциональность будет использоваться) и из количества номенклатур, поставщиков, клиентов, количества складских транзакций, количества финансовых транзакций, наличия интеграций и т.д. Это все указывается в опросном шаблоне перед выходом в продакшн.
Если говорить конкретно про 7 наших виртуальных машин, то их роли такие — БД, 4 сервера приложений, 2 сервера отчетности.
Могу ответить про сайзинг виртуальных машин, которые мы используем для разработчиков — это OneVM DevBox в Azure Standard E8 v3 (8 vcpus, 64 GiB memory)CrushBy
25.07.2019 20:39Извините, но не очень понял. У вас было два варианта размещения Dynamics: либо в их облаке с неизвестной инфраструктурой, либо on-premise на своей инфраструктуре. Как я понимаю, вы заполняете опросник, а они говорят какие виртуальные машины в вашей инфраструктуре требуются в продакшене. Они вам сказали, что нужно 7 машин, но не указали каких именно?
sgots Автор
26.07.2019 13:46Прошу прощения, если не совсем точно объяснил. История с чеклистом для клауда работает так, что он не возвращается назад к клиенту, на основании него MS принимает решение, какого масштаба нужна инфраструктура под клиента в облаке, и ее готовит. В итоге мы просто получили по факту тот набор серверов, который я описал.
В случае решения клиента запускать D365 on-premise, насколько я понимаю, этот чек-лист подгружается в утилиту hardware estimator на портале LCS, и клиент получает рекомендации по сайзингу, но решение остаётся окончательно за ним. Кстати, я могу попробовать прогнать наш чек-лист через эту утилиту и поделиться результатом.CrushBy
26.07.2019 13:51Спасибо за ответ.
История с чеклистом для клауда работает так, что он не возвращается назад к клиенту, на основании него MS принимает решение, какого масштаба нужна инфраструктура под клиента в облаке, и ее готовит
То есть эти 7 виртуальных машин — это именно в облаке? А цены на эти 7 виртуальных серверов одинаковые? Или там просто цены за пользователя и эти 7 машин — это просто справочная информация?
Кстати, я могу попробовать прогнать наш чек-лист через эту утилиту и поделиться результатом.
Было бы очень интересно.sgots Автор
26.07.2019 14:54Цены только за пользователей.
А результатами оценки сайзинга поделюсь в ближайшее время.
MockBeard
26.07.2019 15:24у вас есть какой-то мониторинг по утилизации виртуальных машин? насколько эффективно они используются и нет ли смысла переити на более слабую или наоборот, более мощную виртуалку?
sgots Автор
26.07.2019 16:35Мониторинг есть. А Вы про какие виртуалки спрашиваете: DevBoxes или продуктивную среду?
ShirokovPN
25.07.2019 20:31MS странные люди, для полного цикла надо минимум 22 сервера. Так к ним еще и добавляется головная боль по обновлению всего этого. Сразу возникает желание работать в облаке. И вот тут в Европе получается фэйл — закон о персональных данных в каждой стране имеет какие-то свои особенности и работать в облаке не представляется возможным. Вы упомянули что вы вторыми в России внедрили 365, как? Без персональных данных? Или у MS появились сервера в России?
CrushBy
25.07.2019 20:43Как я понял вторыми, кто использует в России, но для автоматизации дочки в Германии. Наверное, поэтому больше никто в России 365 не использует, так как есть проблема с персональными данными, если использовать для российских процессов.
sgots Автор
25.07.2019 21:10Кстати, MS обещал плагин по работы с персональными данными, если еще не выпустил. Суть плагина состоит в том, чтобы настроенные данные, которые компания считает персональными, сначала складывать на российские сервера, и только потом сохранять в облако Azure. К сожалению, в России датацентров у MS действительно нет.
CrushBy
26.07.2019 09:46Пристально не следил за законодательством РФ в области персональных данных, но разве там смысл не в том, чтобы не хранить их за границей вообще? В чем тогда смысл, если они будут и там и там? Ведь чем больше мест хранения, тем больше вероятность утечки их.
artoym
26.07.2019 10:53Смысл их хранить в России и в первую очередь в России, чтобы всегда можно было произвести кхмм… «контролируемую утечку в компетентные органы».
vladalmazov
25.07.2019 21:15Законодательство РФ (а именно ФЗ-152) накладывает ограничение на обработку персональных данных, предписывая осуществлять сбор и актуализацию (в понятиях Роскомнадзора) таких данных на серверах, расположенных на территории РФ, а хранение — допускается на территории стран, присоединившихся к конвенции «о ПдН». В нашей реализации (Lamoda) сбор и актуализация ПдН осуществляется в on-premise информационных системах и БД, сервера которых расположены на территории РФ. В 365 используется «копии» этих данных.
ShirokovPN
26.07.2019 07:33Вижу что вы написали, но судя по тому, что «вторые в России внедрили в Германии» — как-то слабо верится то, что это именно так.
vladalmazov
26.07.2019 08:48В 365 для Германии (то, о чем рассказывается в статье) нет вообще персональных данных граждан РФ. Там — соответствие GDPR.
takeon
25.07.2019 23:19«В Европе приняты трудовые законы, поэтому внедрение и разборки с законами выполняли российские специалисты».
Классически, по-менеджерски завуалированная издёвка над людьми, которые вкалывали по 12 часов при зарплате явно несравнимой с европейской.LeshaLS
26.07.2019 10:50Не так уж она и несравнима, если вычесть налоги. Я думаю никто в России с плетью над ними не стоял. При желании всегда можно сменить компанию, если заставляют работать в нерабочее время.
Schalker
25.07.2019 23:35Отличная статья
Особенно комментарий о преимуществах облачного решения.
Всего 7 VM на 20 пользователей? Счастливчики.
А как вам локальная инфраструктура на 200 юзеров и вынесенный в облако WebShop? Даже сказать страшно Сколько VM.
justboris
25.07.2019 23:51Здание на фото, кстати, – это Rocket Internet Tower, инкубатор стартапов. Оттуда, например, происходит и немецкий аналог Lamoda – Zalando
Varets
25.07.2019 23:55есть трудности с интеграцией с немецким банком
Можете немного подробнее рассказать в чем трудности? Это проблема конкретного банка или европейских банков в целом? Или проблема не а банке а исключительно в сроках?sgots Автор
26.07.2019 13:39Трудности с интеграцией связаны прежде всего с ограничениями стандартного функционала по генерации файлов для интернет-банка по международным и местным платежам, который не позволяет, например, объединять в одну платежку несколько платежей (за несколько инвойсов) с одинаковыми реквизитами, при этом корректно указывая в назначении платежа весь список исходных документов, за которые идет оплата.
Также была чисто техническая проблема с кодировкой создаваемых файлов — D365 генерит их в UFT-8, а интернет банк ожидает только ANSI.
И ещё есть заморочка с факторингом: либо мы не научились его "готовить", либо в немецкой локализации нет этого функционала.Varets
26.07.2019 16:11Интересно. А как решаются такие технические проблемы (я про кодировку, например)? Вы обращаетесь к вендору, или сами дописываете какие-то дополнительные обработки?
sgots Автор
26.07.2019 20:21Если в целом, то проблемы решаем самостоятельно доработками. Именно эту пока еще не решили.
Terras
26.07.2019 11:15«Российских клиентов, использующих облачное решение этой системы, почти нет (если быть точнее — мы стали вторыми), но для наших целей оно подходило лучше всего.»
Есть же компания Норбит, которая как раз внедряет решения от MS. Или они не к облаку делают?sgots Автор
26.07.2019 13:49Норбит — далеко не единственная консалтинговая компания — партнёр Microsoft, занимающаяся внедрением ERP Microsoft. Но именно клаудную версию D365 мы запустили вторыми.
DenisTrunin
26.07.2019 16:38А как делали тестирование?
И как планируете иметь дело с ежемесячными обновлениями данной системы?sgots Автор
26.07.2019 16:48Тестирование на текущий момент делаем вручную.
Обновления регулярно накатываем, и пока процесс нравится. Пользуемся вариантом с объединением package'а обновления с моделью собственных разработок, и единым пакетом деплоим. Тестируем обновленное приложение в SAT environment, затем выкатываем в прод.
Большие ожидания связаны с недавно анонсированной утилитой автоматических регрессионных тестов.
CrushBy
Что мне всегда нравилось в ERP в Европе, что там особо никто не парится документами строгой отчетности и прочей бумажной волокитой. Приезжает машина, водитель дает планшет, ты расписываешься, что получил 5 коробок непонятно чего. Дальше тебе в конце месяца выставляют инвойс на все содержимое коробок за месяц. Это конечно все значительно проще, чем в СНГ. Правда потом бывало, что привезли одно, а инвойс на немного другое, но это уже другая история.
Спасибо за статью. А можете вкратце рассказать, как вы дорабатываете «облачное решение»? Допустим там есть стандартные модули с функционалам каким-то. Дальше доделываются плагины или как? Например, надо добавить на форму Purchase Order какую-то колонку или поле (и в базу тоже). Как это происходит, и как потом это все поддерживается при обновлении базового продукта Dynamics?
sgots Автор
В новой версии Dynamics 365 Microsoft полностью изменил идеологию разработки и кастомизации приложения — теперь все делается через расширения (extensions). При этом расширения доступны далеко не для всех стандартных алгоритмов, что, с одной стороны, добавляет головной боли разработчику, а, с другой стороны, мотивирует подумать над внедряемым процессом и попытаться изменить процесс, а не систему.
Цели вендора тоже понятны — сделать приложения клиентов всегда актуальными с минимальными трудозатратами. Ведь не секрет, что для классической ERP обновление версии зачастую равнозначно новому внедрению.
CrushBy
Спасибо за ответ. А можно где-то почитать в онлайне про этот механизм?
И можете все-таки по моему примеру: как расширить форму заказа на закупку или продажу. Например, хочется добавить какую-то волшебный параметр, а затем пересчитывать цены в заказе на основе параметра. Как это в общих чертах делается?
sgots Автор
Конечно, можно. Вот домашняя страница про расширения.
Если вкратце, то для таблицы заказов на покупку нужно создать расширение, добавить в него новое поле (параметр). Дальше все зависит от задачи. Если это отдельная кнопка по пересчету цен, то можно создать свой класс с логикой расчета, для вызова класса создать MenuItem, для формы также сделать Extension, в который положить новый MenuItem. Если есть необходимость вклиниться с новым параметром в существующую логику расчета, то нужно смотреть возможность расширения этих стандартных классов. Можно также сделать делегаты на события, в которые включить нужную логику расчета цен, например, при изменении нашего нового параметра запустить логику расчета цен.
ShirokovPN
А как вы оценивали плановые трудозатраты? Ведь найти место куда можно вклиниться часто сопоставимо с тем, что нужно сделать. Сразу умножали на 2? :)
CrushBy
Не очень понимаю, в чем сложность. Взял форму и добавил. В ней посмотрел DataSource и туда добавил поле. Другое дело, что если не сделали «точку входа», чтобы вклиниться в расчет или события, то или нельзя сделать, или по старинке — overlayering, как я понял.
sgots Автор
Overlaying больше не работает
sgots Автор
Примерно так и делали. Это связано ещё с новой схемой программирования и переноса кастомизаций моделями, хоть модели и были в предыдущих версиях. Например, сначала мы делали разные модели для разных блоков функциональности. Потом пришли к выводу, что проще не множить зависимости между библиотеками (dll), и весь свой код иметь и деплоить одной моделью