Проследите ветку с начала — началось все с этого воспоминания времен v7.0, когда человеку предложили написать на ней биллинг, v8 тогда не было: habr.com/en/post/480658/#comment_21028146
Написать биллинг на 1С v6 это нет.
А на v7 уже реально. Она была довольно шустрой, если знать как её готовить. Быстрее чем v8 (на огромных масштабах данных v8 быстрее, но биллингу совсем не обязательно все данные перебирать, достаточно ограничиться «горячими»).
То есть то, что законодатель просто увидел косяки применения ЭП на практике и поспешил их исправить, вы даже не допускаете как мысль? Только сui prodest? )))
только к своей СУБД — это важно. 1С монолит и все начиная от структуры данных до форм отчетов пользователь будет получать из 1С. Да да да, технически возможно, но практически только из экосистемы 1С.
1С не модульное решение, в отрыве от любой части своей экосистемы она на практике не выживает.
Речь конкретно об 1C v7.
Формат её данных довольно прост.
Файловая БД — это стандартный DBF. Что значат какие поля — нетрудно догадаться. Да и описания готовые есть.
Вариант v7 под SQL — обладает той же структурой данных (в результате она плохо адаптирована под реляционные СУБД, так как рождена была для файловых).
Существуют (ну или точнее существовали) продукты, которые напрямую извлекали данные из БД 1С.
начнем с простого — дата в 7.0 (которая в языке была доступна) не предполагала времени от слова совсем.
Ну и в голых СУБД дата со временем появилась не сразу.
Обходились как-то.
Скажем использовать целое число в формате unix timestamp. Или даже строку.
Возможности интеграции 7.0 — только COM, dbf и текстовые файлы.
http с официальной внешней компонентой v7plus
Да и перечисленного вами вполне хватило бы для очень многих задач. Было бы желание.
Точнее, если вопрос стоял так:
Много денег и обязательно 1С — вполне можно сделать полноценный биллинг на 1С. С файловой базой данных 1Сv7 довольно шустра была.
В интерфейсе 7.0 отсутствовало столько возможностей, что я их перечислять устану
А нужны ли они?
Вон, системы заказа авиабилетов до сих пор с текстовыми терминалами работают.
Базового функционала интерфейса 1С для очень многих вещей более чем достаточно.
Конечно, можно сделать изящнее на более развитой по интерфейсу платформе. Но разве это обязательно?
Ведь директор, скорее всего, потому и хотел 1С, чтобы не переучивать персонал на другой интерфейс.
А написать это было нельзя. Я не считаю, что 1с-ник должен любой ценой запихать платформу в любую видимую дырку. Ведь потом с этим надо будет как-то жить.
Если речь не идет о миллионах абонентов (а в описанном вами случае скорее речь о десятках тысяч в пике) то вполне можно.
В те годы только предоплатная система была у операторов связи. И даже биллинги ведущих МТС/Билайна мало что умели в оперативном режиме делать.
Разумеется, каждой задаче свой инструмент.
Например, оперативный сегмент написать на другом инструменте. И подгружать в 1С данные для дальнейшей не спешной обработки.
Я обратил внимание на вашу фразу:
«Мне предложили написать биллинг на 1С и директор очень огорчился когда я отказался».
Если огорчение директора можно было уменьшить взяв у него денег побольше, то почему бы и нет.
Тогда возьмем итог статьи где сказано — «1С это фреймворк быстрой разработки приложений (RAD) для бизнеса и заточен под это.»
РЖД бизнес? 1С Фреймворк?
зачеркните лишнее.
По поводу абсолютно любого инструмента можно найти примеры, где он не работает или работает плохо.
Впрочем, полагаю автор процитированного вами имел ввиду — не для бизнеса, а для учёта в бизнесе.
1С и в телекоме можно использовать.
Только разумеется не в обработке миллионов звонков с оперативным разрывом связи, когда деньги заканчиваются на балансе. А, скажем, в учете прибылей и издержек — 1С вполне себе подходит и для телекома.
Представьте, что вы средней руки компания, например, из Польши или Германии. И у вас есть нужда в автоматизации бизнеса. История эта обычно довольно мозгоемкая, а иногда и капиталоемкая. В любом случае вам хочется решения «всерьез и надолго». А в России вы знаете, что не очень стабильно все.
Разработка будет вестись местными партнерами.
От того, что головное подразделение, которое разаботкой платформы (типовые конфигурации из РФ не нужны за границей) занимается вдруг сменится собственник — вы даже не факт что заметите.
По крайней мере не средней руки, а довольно крупные торговые сети, при вхождении на рынок России, зачастую вполне себе адаптируют свои системы руками именно что местных подразделений.
На Хабре есть статьи сети стройматериалов из Франции, если не ошибаюсь.
Там процесс разработки расписан и доводы, почему поручили нашему подразделению (тому ИТ-подразделению сети французской, что в РФ). А потом им и Казахстан поручили. Просто потому что отдел сильный. Просто потому что им проще с казахстанцами разговаривать.
Нормальный бизнес взвешивает и потом принимает решения.
Бизнес, что принимает решения на основании только эмоциональных факторов, которые вы тут привели — не может быть успешным.
Во времена 7.0 мне предлагали написать на этой платформе биллинг сотовой связи DAMPS. И директор конторы, где я тогда работал, очень сильно расстраивался после того, как на переговорах я открестился от этой идеи.
Возможно вы зря открестились.
Если учесть при написании решения с нуля — платформа 1С предоставляет всего лишь довольно шустрый интерфейс доступа к СУБД (если не использовать автоматику 1С по работе с СУБД типа расчетов итогов регистров).
Директор то не знал, что написанное с нуля решение не позволит ему в дальнейшем ни нанимать дешевых программистов ни не переучивать пользователей.
Ему вполне можно было сказать — вот результат на 1С, давай деньги.
А еще честнее было объяснить — что даже если написать на 1С и даже когда она работает, то ему не получится сэкономить как я выше написал.
Так-то я видел биллинги написанные на чем угодно. На PHP и MyMSL, например. Включая ядро биллинга. Причем на том движке MySQL, что без полноценной поддержки транзакций. Строго говоря, может и не надо транзакций — зато быстро.
Просто потому что руководству фирмы попался именно что веб-программист, которые более ничего не знал.
Сколько разных проектов видел — именование сущностей стандартно делается на английском, этих сущностей не так много и даже не зная английского запомнить их не сложно.
1) Ну это вы такие проекты видели. Я вот видел наименования сущностей на итальянском и французском — это жесть, работать невозможно, если ты языка не знаешь.
2) А еще зачастую встречал, когда из-за слабого знания языка термины прикладной области или воспринимаются программистами с ошибками (что вообще страшно) или попросту разработка идет крайне медленно.
Ваша ситуация когда все просто — когда речь идет об универсальных терминах. Стоит копнуть глубже, погрузившись в предметную область (если эта область не ИТ), то все — приехали, вокруг вас фактически иероглифы. И вроде бы разжеванное другим разработчиком длинное название метода/класса/переменной дает вам не больше понимания о программе, чем просто i1, i2, i3.
Помню как после обновления сервер предприятия перестал падать 2-3 раза в день, и в этом обновлении появились процессы в этом сервере предприятия, но падать он не перестал, просто падал реже, а бизнес тот круглосуточный и в договорах за простои штрафы. Вы ведь заметили что я обсуждаю продукт из коробки, главную модель продажи 1С?
Вряд ли тут проблема самой 1С.
Мне кажется, что тут проблема в конкретных специалистах.
Возможно, в руководстве, что не одобрила финансирование решений на другой платформе/глубокую доработку 1С.
Возможно, в технических специалистах.
Например, такое часто бывает при бурном росте, когда вчера ты был эникей, сегодня сисадмин, а завтра начальник отдела ИТ, но знания у тебя так фантастически не выросли, как название твоей должности/зарплата.
Другая компания в этом же холдинге изначально использовала Oracle на самом нагруженном по данным направлении и не знала таких проблем.
Узкоспециализированное решение (написанное грамотным разработиком конечно) завсегда будет иметь преимущество в этом пункте перед решением универсальным.
Другое дело, что узкоспециализированное быстрое решение — еще и малофункциональное и не гибкое. И разработка/доработка его не дешёва и не быстра (кроме самый примитивных ситуаций).
Поэтому нужно балансировать:
Когда-то выгоднее использовать уже готовое универсальное,
а когда выгоднее узкоспецилизированное созданное под конкретную задачу.
В остальных случаях где бизнес логика сильно отличается от торговли ,1С не работает
А зачем брать в качестве основы для такого бизнеса торговую конфигурацию от 1С?
Полно же специализированных решений.
Да и торговля — для многих видов деятельности вполне универсальный механизм.
Лично адаптировал торговые конфигурации под различные производства, к примеру. Там львинная доля кода все так же переиспользуется.
Самые серьезные доработки только для одного единственного документа «Выпуск продукции с расчетом издержек». Очевидно, что в торговой конфигурации такого нет.
В ответ на вопрос: а зачем: тут решает доступность специалиста. Внедрять и поддерживать изначально специализированное решение, но с которым никто не знаком в ближайшем окружении — далеко не всегда выгоднее, чем просто допилить под себя то, что ты уже знаешь.
Но не спорю, что, разумеется, всегда можно найти сферу деятельности под которую 1С не годится.
Дело вообще не в простоте для новичков. И совсем не в том, что синтаксис на родном языке, и так в чём-то легче.
Это просто удобно. Это просто ОЧЕНЬ удобно!
Из-за отсутствия на русской раскладке некоторых символов пунктуации, что есть только в латинской — есть и неудобства.
Но использование названий объектов прикладной области на языке, что ты знаешь с детства, а не начал учить только в школе — да, это безусловно удобно.
«Вычет на ребенка с налога на доходы физических лиц» в английском переводе только путает программиста, это да.
Если только речь не идет об автоматизации какого-нибудь британского предприятия, коим владеет бывший наш и по ностальгии внедряющий у себя на предприятии 1С.
В корне неверное мнение, покупка коробки — это да, тьфу копейки. Но на этом только все начинается. Я знаю очень много заваленных примеров внедрения решений 1С, тут можно назвать и УТ, и УПП, и ERP, местами даже ЗУП умудряются завалить. Вот в чем проблема.
Я этим занимаюсь профессионально очень много лет. Видел и удачные внедрения без каких-либо доработок вовсе. Видел и переписанные с нуля.
Утверждаю, что типично — всего лишь очень небольшие изменения вносятся в код. Этого достаточно подавляющему большинству предприятий для начала эксплуатации 1С: Предприятия.
Потом, возможно, будут еще доработки. Но для начала эксплуатации множество доработок при внедрении — не типичная ситуация.
Не означает, конечно, что описанной вами ситуации нет в принципе. Отчего же — есть. Но нечасто.
Я эти ситуации в своей карьере хорошо помню, так как это хорошие деньги мне лично. К сожалению они не типичны, не часты.
Разумеется.
Бизнес не стал бы платить, если ли бы для него это были действительно существенные деньги.
Фокус в том, что «для предприятия копейки, а для человека очень даже дофига».
Нет, это не копейки, очень серьезная работа с довольно большим порогом вхождения, с очень крепкими нервами, ну и с высокими зарплатами.
И наверняка, бизнес хотел бы это исправить, но пока не может.
Не вижу никакой неразрешимой проблемы.
Есть только одна-единственная сложность: всё дело только в том, что за человек занимается принятием решений — где брать типовую, а где пилить своё.
Какова квалификация этого конкретного человека и каковы конкретные требования бизнеса.
Но сдох. Быстро по историческим меркам. У капитализма, чсх — более длинный аптайм.
Что как бы свидетельствует.
Это всего лишь формальные названия одни и те же. Нынешний капитализм от капитализма конца 19-го века отличается более чем существенно.
Тогдашние рабочие были почти что рабами. Дикий капитализм. Даже за смерть работающих детей на производстве — не привлекали, это же не умышленное убийство.
Нынешние сотрудники — зачастую что и диктуют условия своим работодателям. Или это диктует работодателям общественное мнение (вспомните хоть историю с самоубийствами на китайском заводе, что собирал iPhone).
Под влиянием революции в России в Европе тоже прошли волны. В результате нынешняя Европа, из боязни власть имущих потерять все, стала куда как более заботливее к простому населению. Ту же скандинавскую модель зачастую называют социализмом.
Тут граница условная. Тот же Китай, формально социалистическая страна. А фактически?
Это все не более чем названия.
Социализм не умер. Он трансформировался.
Как трансформировался и капитализм.
Другое дело, что в стране первой построившей социализм — люди шарахнулись в категорически другую сторону. Это нормально для людей.
Сколько с 1С работал — 99% задач было именно что-то из разряда: «у нас типовая на типовую не накатилась, иди разберись», «вышло постановление ФНСГРУФСБМЧСГКЧП о том что форма дока изменилась, и теперь нужно запятую поставить вот тут, а это подчеркивание перенести туда, типовая еще не обновилась — давай сделай»… Самое интересное было что-либо из разряда «у нас вот приходят письма по электронке с прайсами, надо бы их автоматически загружать».
Пока был джуном — это все было не то что-бы сильно интересно, но норм, а дальше…
Вы сейчас описали типичные задачи для джуна — не более.
Мне почему-то все больше попадалась «нестандартная интеграция с внешним софтом», «существенное изменение движения по регистрам для таких то целей», «навороченная система ценообразования, скидок и бонусов» и т.п.
Фактически вы работали в поддержке, а не в разработке.
Идея 1С с типовыми конфигурациями — как раз и означает, что большая часть работы — это именно поддержка.
Но я изначально ориентировался на разработку, так что описанных вами неинтересных задач у меня был самый мизер.
А при чем тут я?
Проследите ветку с начала — началось все с этого воспоминания времен v7.0, когда человеку предложили написать на ней биллинг, v8 тогда не было:
habr.com/en/post/480658/#comment_21028146
Написать биллинг на 1С v6 это нет.
А на v7 уже реально. Она была довольно шустрой, если знать как её готовить. Быстрее чем v8 (на огромных масштабах данных v8 быстрее, но биллингу совсем не обязательно все данные перебирать, достаточно ограничиться «горячими»).
Вполне допускаю.
Но что-то уж очень быстро.
Обычно далеко не так все быстро с законами.
Речь конкретно об 1C v7.
Формат её данных довольно прост.
Файловая БД — это стандартный DBF. Что значат какие поля — нетрудно догадаться. Да и описания готовые есть.
Вариант v7 под SQL — обладает той же структурой данных (в результате она плохо адаптирована под реляционные СУБД, так как рождена была для файловых).
Существуют (ну или точнее существовали) продукты, которые напрямую извлекали данные из БД 1С.
Это не сложно для программиста средней руки.
Ну и в голых СУБД дата со временем появилась не сразу.
Обходились как-то.
Скажем использовать целое число в формате unix timestamp. Или даже строку.
http с официальной внешней компонентой v7plus
Да и перечисленного вами вполне хватило бы для очень многих задач. Было бы желание.
Точнее, если вопрос стоял так:
Много денег и обязательно 1С — вполне можно сделать полноценный биллинг на 1С. С файловой базой данных 1Сv7 довольно шустра была.
А нужны ли они?
Вон, системы заказа авиабилетов до сих пор с текстовыми терминалами работают.
Базового функционала интерфейса 1С для очень многих вещей более чем достаточно.
Конечно, можно сделать изящнее на более развитой по интерфейсу платформе. Но разве это обязательно?
Ведь директор, скорее всего, потому и хотел 1С, чтобы не переучивать персонал на другой интерфейс.
Если речь не идет о миллионах абонентов (а в описанном вами случае скорее речь о десятках тысяч в пике) то вполне можно.
В те годы только предоплатная система была у операторов связи. И даже биллинги ведущих МТС/Билайна мало что умели в оперативном режиме делать.
Разумеется, каждой задаче свой инструмент.
Например, оперативный сегмент написать на другом инструменте. И подгружать в 1С данные для дальнейшей не спешной обработки.
Я обратил внимание на вашу фразу:
«Мне предложили написать биллинг на 1С и директор очень огорчился когда я отказался».
Если огорчение директора можно было уменьшить взяв у него денег побольше, то почему бы и нет.
Технически задача вполне себе реализуема.
По поводу абсолютно любого инструмента можно найти примеры, где он не работает или работает плохо.
Впрочем, полагаю автор процитированного вами имел ввиду — не для бизнеса, а для учёта в бизнесе.
1С и в телекоме можно использовать.
Только разумеется не в обработке миллионов звонков с оперативным разрывом связи, когда деньги заканчиваются на балансе. А, скажем, в учете прибылей и издержек — 1С вполне себе подходит и для телекома.
Кому-то нравится делать под веб, а кому-то под смартфоны.
Кому-то нравится делать игры, а кому-то СУБД оптимизировать.
И т.д.
Разработка будет вестись местными партнерами.
От того, что головное подразделение, которое разаботкой платформы (типовые конфигурации из РФ не нужны за границей) занимается вдруг сменится собственник — вы даже не факт что заметите.
По крайней мере не средней руки, а довольно крупные торговые сети, при вхождении на рынок России, зачастую вполне себе адаптируют свои системы руками именно что местных подразделений.
На Хабре есть статьи сети стройматериалов из Франции, если не ошибаюсь.
Там процесс разработки расписан и доводы, почему поручили нашему подразделению (тому ИТ-подразделению сети французской, что в РФ). А потом им и Казахстан поручили. Просто потому что отдел сильный. Просто потому что им проще с казахстанцами разговаривать.
Нормальный бизнес взвешивает и потом принимает решения.
Бизнес, что принимает решения на основании только эмоциональных факторов, которые вы тут привели — не может быть успешным.
Это зачем им?
Ведь полное еще 32-битный аппаратов.
Возможно вы зря открестились.
Если учесть при написании решения с нуля — платформа 1С предоставляет всего лишь довольно шустрый интерфейс доступа к СУБД (если не использовать автоматику 1С по работе с СУБД типа расчетов итогов регистров).
Директор то не знал, что написанное с нуля решение не позволит ему в дальнейшем ни нанимать дешевых программистов ни не переучивать пользователей.
Ему вполне можно было сказать — вот результат на 1С, давай деньги.
А еще честнее было объяснить — что даже если написать на 1С и даже когда она работает, то ему не получится сэкономить как я выше написал.
Так-то я видел биллинги написанные на чем угодно. На PHP и MyMSL, например. Включая ядро биллинга. Причем на том движке MySQL, что без полноценной поддержки транзакций. Строго говоря, может и не надо транзакций — зато быстро.
Просто потому что руководству фирмы попался именно что веб-программист, которые более ничего не знал.
1) Ну это вы такие проекты видели. Я вот видел наименования сущностей на итальянском и французском — это жесть, работать невозможно, если ты языка не знаешь.
2) А еще зачастую встречал, когда из-за слабого знания языка термины прикладной области или воспринимаются программистами с ошибками (что вообще страшно) или попросту разработка идет крайне медленно.
Ваша ситуация когда все просто — когда речь идет об универсальных терминах. Стоит копнуть глубже, погрузившись в предметную область (если эта область не ИТ), то все — приехали, вокруг вас фактически иероглифы. И вроде бы разжеванное другим разработчиком длинное название метода/класса/переменной дает вам не больше понимания о программе, чем просто i1, i2, i3.
Вы вряд ли придете к одной точки зрения с вашим оппонентам.
Но по другой причине:
Эти вещи нужно рассматривать не столь абстрактно, а только относительно конкретной прикладной задачи. И с конкретными программистами.
А ощущения тут совершенно не при чём.
Ага:
1) Кроме конечных точек продаж, в которых и образуется прибыль.
2) И вовсе не по описанным вами выше причинам, а по причине дешивизны рабочей силы.
О. Да вы типичный пример привели. Серьезно. Типичный?
Не стоит переживать за РЖД при их-то финансовых возможностях.
Впрочем я на это ваше высказывание уже ответил заранее:
habr.com/en/post/480658/#comment_21028022
Вряд ли тут проблема самой 1С.
Мне кажется, что тут проблема в конкретных специалистах.
Возможно, в руководстве, что не одобрила финансирование решений на другой платформе/глубокую доработку 1С.
Возможно, в технических специалистах.
Например, такое часто бывает при бурном росте, когда вчера ты был эникей, сегодня сисадмин, а завтра начальник отдела ИТ, но знания у тебя так фантастически не выросли, как название твоей должности/зарплата.
Узкоспециализированное решение (написанное грамотным разработиком конечно) завсегда будет иметь преимущество в этом пункте перед решением универсальным.
Другое дело, что узкоспециализированное быстрое решение — еще и малофункциональное и не гибкое. И разработка/доработка его не дешёва и не быстра (кроме самый примитивных ситуаций).
Поэтому нужно балансировать:
Когда-то выгоднее использовать уже готовое универсальное,
а когда выгоднее узкоспецилизированное созданное под конкретную задачу.
А зачем брать в качестве основы для такого бизнеса торговую конфигурацию от 1С?
Полно же специализированных решений.
Да и торговля — для многих видов деятельности вполне универсальный механизм.
Лично адаптировал торговые конфигурации под различные производства, к примеру. Там львинная доля кода все так же переиспользуется.
Самые серьезные доработки только для одного единственного документа «Выпуск продукции с расчетом издержек». Очевидно, что в торговой конфигурации такого нет.
В ответ на вопрос: а зачем: тут решает доступность специалиста. Внедрять и поддерживать изначально специализированное решение, но с которым никто не знаком в ближайшем окружении — далеко не всегда выгоднее, чем просто допилить под себя то, что ты уже знаешь.
Но не спорю, что, разумеется, всегда можно найти сферу деятельности под которую 1С не годится.
Из-за отсутствия на русской раскладке некоторых символов пунктуации, что есть только в латинской — есть и неудобства.
Но использование названий объектов прикладной области на языке, что ты знаешь с детства, а не начал учить только в школе — да, это безусловно удобно.
«Вычет на ребенка с налога на доходы физических лиц» в английском переводе только путает программиста, это да.
Если только речь не идет об автоматизации какого-нибудь британского предприятия, коим владеет бывший наш и по ностальгии внедряющий у себя на предприятии 1С.
Я этим занимаюсь профессионально очень много лет. Видел и удачные внедрения без каких-либо доработок вовсе. Видел и переписанные с нуля.
Утверждаю, что типично — всего лишь очень небольшие изменения вносятся в код. Этого достаточно подавляющему большинству предприятий для начала эксплуатации 1С: Предприятия.
Потом, возможно, будут еще доработки. Но для начала эксплуатации множество доработок при внедрении — не типичная ситуация.
Не означает, конечно, что описанной вами ситуации нет в принципе. Отчего же — есть. Но нечасто.
Я эти ситуации в своей карьере хорошо помню, так как это хорошие деньги мне лично. К сожалению они не типичны, не часты.
Разумеется.
Бизнес не стал бы платить, если ли бы для него это были действительно существенные деньги.
Фокус в том, что «для предприятия копейки, а для человека очень даже дофига».
Не вижу никакой неразрешимой проблемы.
Есть только одна-единственная сложность: всё дело только в том, что за человек занимается принятием решений — где брать типовую, а где пилить своё.
Какова квалификация этого конкретного человека и каковы конкретные требования бизнеса.
Это всего лишь формальные названия одни и те же. Нынешний капитализм от капитализма конца 19-го века отличается более чем существенно.
Тогдашние рабочие были почти что рабами. Дикий капитализм. Даже за смерть работающих детей на производстве — не привлекали, это же не умышленное убийство.
Нынешние сотрудники — зачастую что и диктуют условия своим работодателям. Или это диктует работодателям общественное мнение (вспомните хоть историю с самоубийствами на китайском заводе, что собирал iPhone).
Под влиянием революции в России в Европе тоже прошли волны. В результате нынешняя Европа, из боязни власть имущих потерять все, стала куда как более заботливее к простому населению. Ту же скандинавскую модель зачастую называют социализмом.
Тут граница условная. Тот же Китай, формально социалистическая страна. А фактически?
Это все не более чем названия.
Социализм не умер. Он трансформировался.
Как трансформировался и капитализм.
Другое дело, что в стране первой построившей социализм — люди шарахнулись в категорически другую сторону. Это нормально для людей.
Вы сейчас описали типичные задачи для джуна — не более.
Мне почему-то все больше попадалась «нестандартная интеграция с внешним софтом», «существенное изменение движения по регистрам для таких то целей», «навороченная система ценообразования, скидок и бонусов» и т.п.
Фактически вы работали в поддержке, а не в разработке.
Идея 1С с типовыми конфигурациями — как раз и означает, что большая часть работы — это именно поддержка.
Но я изначально ориентировался на разработку, так что описанных вами неинтересных задач у меня был самый мизер.