Вопрос наверное риторический, но очень нужны грамотные советы, советы людей которые сталкивались с похожей проблемой. Надеюсь на ваше понимание.
Я по сути один программист на фирме, кто занимается 8.ХХ. Фирма предлагает комплексное решение для клиентов на базе 7.7, где есть ведение учета, калькуляция, начисление заработной платы со всеми вытекающими, и тп.
Т.е. была лет 10 назад типовая конфигурация на 7.7, её переделали, отказались от обновлений и по сути сделали свою типовую конфигурацию для всех клиентов.
Мне поставили задачу реализовать функционал в 8.3 сделанный на 7.7.
1. Возникает сразу вопрос, по какому пути двигаться? Брать какую-нибудь типовую конфигурацию вроде БП или Комплексной автоматизации и дорабатывать их, но сразу же вытекает ещё один вопрос, а что с обновлениями в будущем? Т.к. изменения нужны будут глобальные, и соответственно чем больше будет изменений, тем проблематичней будут обновления от типовых. Считаю этот вариант событий не рациональным.
2. Использовать Расширения, но поработав с ними, функционал у них ограничен.
3. Писать конфигурацию с нуля, но нужно много времени и явно больше программистов.
4. Брать какую-нибудь типовую конфигурацию вроде БП или Комплексной автоматизации и дорабатывать их, забивая на обновления. По мне так это оптимальный вариант.
Вроде бы все свои варианты написал, надеюсь есть другие.
Если есть желающие поработать над такой задачей, пишите в ЛС, оплата обсуждаема. (Речь идет о конфигурации для Республики Беларусь).
PS
Пример задачи при переносе:
- добавление новых реквизитов
- изменение типовых форм документов
- изменение длины стандартных реквизитов
Я по сути один программист на фирме, кто занимается 8.ХХ. Фирма предлагает комплексное решение для клиентов на базе 7.7, где есть ведение учета, калькуляция, начисление заработной платы со всеми вытекающими, и тп.
Т.е. была лет 10 назад типовая конфигурация на 7.7, её переделали, отказались от обновлений и по сути сделали свою типовую конфигурацию для всех клиентов.
Мне поставили задачу реализовать функционал в 8.3 сделанный на 7.7.
1. Возникает сразу вопрос, по какому пути двигаться? Брать какую-нибудь типовую конфигурацию вроде БП или Комплексной автоматизации и дорабатывать их, но сразу же вытекает ещё один вопрос, а что с обновлениями в будущем? Т.к. изменения нужны будут глобальные, и соответственно чем больше будет изменений, тем проблематичней будут обновления от типовых. Считаю этот вариант событий не рациональным.
2. Использовать Расширения, но поработав с ними, функционал у них ограничен.
3. Писать конфигурацию с нуля, но нужно много времени и явно больше программистов.
4. Брать какую-нибудь типовую конфигурацию вроде БП или Комплексной автоматизации и дорабатывать их, забивая на обновления. По мне так это оптимальный вариант.
Вроде бы все свои варианты написал, надеюсь есть другие.
Если есть желающие поработать над такой задачей, пишите в ЛС, оплата обсуждаема. (Речь идет о конфигурации для Республики Беларусь).
PS
Пример задачи при переносе:
- добавление новых реквизитов
- изменение типовых форм документов
- изменение длины стандартных реквизитов
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
1. Добавление своих реквизитов на обновление не влияет.
2. Сделай механизм добавления новых реквизитов на формы динамически. Можно будет добавлять с минимальными доработками. На ИС есть разные примеры как это сделать.
3. Лучше создать свои реквизиты чем менять длину, состав типов и тд у реквизитов из типовой. Меньше проблем с обновлением и если понадобится потом обмен с какой либо типовой по каким то стандартным документам будет меньше проблем с обменом.
2. Сделай механизм добавления новых реквизитов на формы динамически. Можно будет добавлять с минимальными доработками. На ИС есть разные примеры как это сделать.
3. Лучше создать свои реквизиты чем менять длину, состав типов и тд у реквизитов из типовой. Меньше проблем с обновлением и если понадобится потом обмен с какой либо типовой по каким то стандартным документам будет меньше проблем с обменом.
(8)что то мне кажется, что дух "нетленки" слишком сильно в вас засел. Насколько я помню для Белоруссии сделали весь спектр типовых, если в них что то не устраивает, то всегда можно дополнить, но при этом получить геморой с обновлением. И судя по всему вы на фирме не знаете функционал типовых.
(1)
У вас очень общий абстрактный вопрос, без деталей.
Нужно знать доработанную функциональность и проанализировать ее связность с выбираемой типовой конфигурацией.
Если, допустим, написана предпродажная CRM-система, из которой только выход заключенных договоров стыкуется с типовой конфигурацией (объекты типа "контрагент", "договор", "заказ"), то имеет смысл ее отделить в отдельную базу и организовать обмен данными с типовой основной учетной базой. В легковесной CRM будет сидеть весь call-центр и менеджеры, а реальный учет в тяжелой типовой конфе ими нагружаться не будет.
А если вы существенно расширяете почти все имеющиеся учетные механизмы регламентированного учета, то вам надо брать типовую конфигурацию, дорабатывать, регулярно накладывать обновления от поставщика конфигурации, и самому транслировать обновленную вашу конфигурацию клиентам (так построены отраслевые решения на базе типовых конф, например Бухгалтерия сельскохозяйственного предприятия (в РФ), где вендор сделал, как минимум, дополнительный количественный учет по животноводству на многих счетах плана счетов, переделал учет затрат и доработал ряд документов типовой бухгалтерии).
И есть ряд промежуточных вариантов:
- отдельная конфигурация с "бесшовной" интеграцией с основной (типа "1С: Документооборот" и его интеграция с УПП/КА, правда ИМХО получается "с подкожными рубцами").
- точечные дописки к основной типовой конфигурации через суперклей, костыли и кузькину мать (дополнительные объекты, свойства/допреквизиты в типовых объектах, подписки на события, расширения, отражение новых документов в учете автоматизированным проведением типовых документов), не препятствующие / мало препятствующие обновлениям)
Вариант писать конфигурацию с нуля, включив туда оперативный учет, я полагаю экстремистским, и возможным только если у вас автоматизировано ограниченное количество процессов (ну, скажем, только продажи, покупки и склад), плюс не требуется регламентированный учет (в смысле, организована выгрузка в типовую конфигурацию регламентированного учета,где негры на планта специально обученные люди занимаются его доводкой в отрыве от оперативного), иначе вы один просто физически не потянете написание конфы, а для регламентированного учета не сопроводите изменения законодательства.
Короче, вы сами практически все варианты написали, но чтобы принять решение или дать совет - нужно спроектировать архитектуру, а для этого нужно хотя бы понимать, что у вас доработано по сравнению с типовой конфигурацией в 7.7, и что это была за конфигурация.
1. Возникает сразу вопрос, по какому пути двигаться? Брать какую-нибудь типовую конфигурацию вроде БП или Комплексной автоматизации и дорабатывать их, но сразу же вытекает ещё один вопрос, а что с обновлениями в будущем? Т.к. изменения нужны будут глобальные, и соответственно чем больше будет изменений, тем проблематичней будут обновления от типовых. Считаю этот вариант событий не рациональным.
У вас очень общий абстрактный вопрос, без деталей.
Нужно знать доработанную функциональность и проанализировать ее связность с выбираемой типовой конфигурацией.
Если, допустим, написана предпродажная CRM-система, из которой только выход заключенных договоров стыкуется с типовой конфигурацией (объекты типа "контрагент", "договор", "заказ"), то имеет смысл ее отделить в отдельную базу и организовать обмен данными с типовой основной учетной базой. В легковесной CRM будет сидеть весь call-центр и менеджеры, а реальный учет в тяжелой типовой конфе ими нагружаться не будет.
А если вы существенно расширяете почти все имеющиеся учетные механизмы регламентированного учета, то вам надо брать типовую конфигурацию, дорабатывать, регулярно накладывать обновления от поставщика конфигурации, и самому транслировать обновленную вашу конфигурацию клиентам (так построены отраслевые решения на базе типовых конф, например Бухгалтерия сельскохозяйственного предприятия (в РФ), где вендор сделал, как минимум, дополнительный количественный учет по животноводству на многих счетах плана счетов, переделал учет затрат и доработал ряд документов типовой бухгалтерии).
И есть ряд промежуточных вариантов:
- отдельная конфигурация с "бесшовной" интеграцией с основной (типа "1С: Документооборот" и его интеграция с УПП/КА, правда ИМХО получается "с подкожными рубцами").
- точечные дописки к основной типовой конфигурации через суперклей, костыли и кузькину мать (дополнительные объекты, свойства/допреквизиты в типовых объектах, подписки на события, расширения, отражение новых документов в учете автоматизированным проведением типовых документов), не препятствующие / мало препятствующие обновлениям)
Вариант писать конфигурацию с нуля, включив туда оперативный учет, я полагаю экстремистским, и возможным только если у вас автоматизировано ограниченное количество процессов (ну, скажем, только продажи, покупки и склад), плюс не требуется регламентированный учет (в смысле, организована выгрузка в типовую конфигурацию регламентированного учета,
Короче, вы сами практически все варианты написали, но чтобы принять решение или дать совет - нужно спроектировать архитектуру, а для этого нужно хотя бы понимать, что у вас доработано по сравнению с типовой конфигурацией в 7.7, и что это была за конфигурация.
(1)
если это не управленческая ЗП , тогда 150% типовая где есть такой функционал.
p/s не знаю как у вас , но в России законодательство по ЗП один из главных геморроев для бухгалтеров
начисление заработной платы со всеми вытекающими
если это не управленческая ЗП , тогда 150% типовая где есть такой функционал.
p/s не знаю как у вас , но в России законодательство по ЗП один из главных геморроев для бухгалтеров
Думаю, что будет конструктивнее, если автор напишет требования для системы. Что она делает сейчас (в реализации на 7.7)?
(32) "теперь это конфигурация для Общепита" Вот оно! Берите соответствующую отраслевую на восьмерке, анализируйте, чего не хватает для соответствия вашей семерочной конфе. Допиливайте.
Очень желательно, чтобы отраслевая была на современной БСП.
Очень желательно, чтобы отраслевая была на современной БСП.
А может все то что дорабатывалось в конфигурации на 7.7 уже реализовано в какой-нибудь современной типовой ?
Значит оптимальным вариантом сейчас будет, определиться с типовой которая наиболее близко подходит к итоговому решению, изучать её и дорабатывать так, что бы потом не было проблем с обновлениями?
"типовая конфигурация на 7.7"
посмотрите такую же на 8.хх, скорее всего она вам подойдет для доработки
посмотрите такую же на 8.хх, скорее всего она вам подойдет для доработки
Если опыт работы 1.5 года, я бы посоветовал вообще не связываться с такой работой, тем более, что поддерживать 200 клиентов. Вам нужна бригада программистов, Вы один пока 200 писем с конфигурацией отправите, пойдет неделя, а то и больше. А что клиенты сумеют сами перейти с 7.7. на 8.3? Не беритесь за грандиозные задачи, если сумеете поддерживать переработанную 7.7 и то хорошо. Если хочется дел громадья, напишите проект новой программы на 8. Пока будете писать, поймете что же вам брать (или куда бечь).
Если с пользователями общаться через рассылки, то скоро точно ничего не потребуется. Особенно в условиях перевода с 7.7 на 8
Думаю, начать стоит с того, чтобы посмотреть, что подобное вашей конфигурации уже написано на 8.3.
Структура базы 7.7 имеет куча недостатков. Ну к примеру одна табличная часть документа, отсутствие подписки на событие. Один план счетов. В 8.3 нужно заново строить архитектуру базы и проще сначала посмотреть, как это делали другие.
Структура базы 7.7 имеет куча недостатков. Ну к примеру одна табличная часть документа, отсутствие подписки на событие. Один план счетов. В 8.3 нужно заново строить архитектуру базы и проще сначала посмотреть, как это делали другие.
Это стандартный вариант развития отраслевого решения.
Берете типовую, функционал которой ближе к задачам ваших пользователей.
Скорее всего это будет БП (российская) или Бухгалтерия для Беларуси.
Переносите в нее свои изменения, минимально затрагивая типовой функционал (свои документы, справочники, общие модули, отчеты, обработки).
При выходе новой версии обновляете в своей типовую часть и рассылаете обновления пользователям.
Если получится реализовать с совсем минимальными изменениями, то продавать можно независимо как модуль. Но у пользователя должна быть куплена своя основная конфигурация.
Если всё вместе, то так как в вашем решении будет использоваться типовая, то часть денег перечисляете с каждой продажи 1С.
Берете типовую, функционал которой ближе к задачам ваших пользователей.
Скорее всего это будет БП (российская) или Бухгалтерия для Беларуси.
Переносите в нее свои изменения, минимально затрагивая типовой функционал (свои документы, справочники, общие модули, отчеты, обработки).
При выходе новой версии обновляете в своей типовую часть и рассылаете обновления пользователям.
Если получится реализовать с совсем минимальными изменениями, то продавать можно независимо как модуль. Но у пользователя должна быть куплена своя основная конфигурация.
Если всё вместе, то так как в вашем решении будет использоваться типовая, то часть денег перечисляете с каждой продажи 1С.
Внимание! Тема сдана в архив
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот