Разработка под 1С — какую архитектуру/технологию выбрать?
Добрый день,
откройте тайну - какие есть современные технологии/методы для разработки решений на 1С (8.2/8.3) с тем, чтобы с одной стороны получить цельный продукт, а с другой - сохранить возможность обновления 1С:Бухгалтерии стандартными обновлениями.
Мои рассуждения на тему, варианты: 1. Писать свое решение на 1С, стыковать его со стандартной 1С:Бухгалтерией через выгрузку (файловые/OLE/веб-сокеты и т.п.). Плюсы:
идеальное обновление типовой 1С:Бухгалтерии Минусы:
две разных программы для бухгалтера и для текущего техпроцесса предприятия, гибкость (загибаемость) выгрузки
необходимость синхронизировать справочники
2. Дописывать стандартную 1С:Бухгалтерию, по-возможности так, чтобы минимум объектов снимать с поддержки и не сильно изменяя (адекватно дополняя) структуру данных Плюсы:
одна программа для техпроцесса внутреннего и бух.учета
отсутствие необходимости синхронизации Минусы:
сложность программы
необходимость полуручного обновления
меньше возможности/гибкости для разработки (не изменишь сильно структуру данных)
рано или поздно поддержка 8.2/8.3 закончится, и придется очень муторно переезжать на более новую платформу/релиз
3.Онлайн-OLE взаимодействие. Пишется своя конфигурация "с нуля", через OLE подхватывает текущую 1С:Бухгалтерию с всеми ее объектами. Дополнительные справочники хранятся в своей новой конфигурации, сопоставляем их с существующими в 1С:Бухгалтерии по UUID. Плюсы:
наши "дописанные" данных хранятся в отдельном от 1С:Бухгалтерии месте Минусы:
необходимость отрисовать свои интерфейсы даже на типовые операции (заведение номенклатуры, например)
мне непонятно, постоянны ли UUID при, допустим, обновлении платформы/конфигурации
Мне не нравится ни один из вышеизложенных вариантов. Наверняка есть адекватная архитектура, если хочется много своего и нового, но при этом не уходить от обновлений.
Вы забыли про еще один способ, который доступен со времен первых восьмерочных решений - находится на поставке у нескольких поставщиков. Можно писать в сторонке свою конфу и делать из нее поставочные релизы. Базу типовой бухи поставить на поддержку еще вашей конфигурации. В результате получаем новые документы и справочники, но основная буха остается по прежнему на полной поддержке. Это в теории, поскольку такой задачи не было, я всегда просто включал возможность редактирования и делал "аккуратные" доработки.
Еще сейчас появилась технология дополнений - точно знаю, что можно включить свои формы, отчеты и обработки. Можно ли включить дополнительные справочники и документы пока не в курсе - руки не дошли тестировать. Такие дополнения можно произвольно включать и отключать, при этом основная конфигурация может находится на полной поддержке.
Еще вариант поставить рядом две идентичные бухи. Одна на полной поддержке, в другой делаете изменения. Но обмены между ними с помощью встроенного механизма обмена по правилам из "конвертация данных". При этом первоначальные правила между идентичными конфигурациями создаются автоматически и вам нужно будет периодически, что-то подправлять, если ваша новая бизнес логика будет влиять на состояние информации в базе-приемнике (к примеру, расширите типы сделок и можете получить непроводимые документы по договору с ведением расчетов по расчетным документам).
Все зависит от уровня вмешательства в стандартную конфу. Дополнительные объекты, не затрагивающие код и структуру стандартных "обновляемость" не затрудняет. Если же необходимо менять структуру и алгоритмы обработки - разделите базы. Синхронизируется через OLE, xml или csv - зависит от объёмов и структуры. И да, учёт в "отчетной" базе обычно ведётся по синтетике, так что со справочниками проблем не возникает.
Например, электронный документооборот Контура, обработка (+модификации конфы небольшие) - просто идеальный пример.
Очень нехилый функционал.
Легко ставится.
Ничему не мешает.
Средний
