Полностью согласен. Толька 1С это не продвинутый Excel а продвинутая СУБД.
Я такими же аргументами оперировал когда в организации где я работал хотели создать свою CRM. Программист на РНР предлагал связку РНР + Apache.
Но после того как посчитали количество часов которое потребуется для того чтобы просто создать справочник контрагентов + некий документ заявка в котором будет использоваться еще несколько справочников то решили что 1С предпочтительнее.
1С позволяет не думать о хранении и взаимодействии данных и полностью сосредоточится на конечном результате. Конечно если мы пишем для крупных организаций с документооборотом по сотне тысяч строк в сутки и о сотнях пользователей в базе — тогда стоит правильно строить архитектуру чтобы в запросах не использовать получение данных через точку и на долго не блокировать таблицы констант (и прочие)
Я начинал с паскаля, потом бейсик, С, С# но потом решил пойти в 1С.
В самом начале даже писал на английском (еще на 7.7) но это быстро прошло.
Как пишется логика-не важно. Но вот доступ к данным — это уже другое и переключать раскладку ради If или For уже лишнее )
С вашего позволения напомню что в данном контексте база 1С — это не код.
Это созданная СУБД с таблицами и связками. Если хотите получить только код и взвесить его выгрузите .cf файл. Это и будет чисто код без БД и прочего.
Это основная причина, по которой компания разрабатывает продукт, который является достаточно унылым по современным меркам.
Если не секрет по каким меркам продукт унылый, и какие современные программные продукты которые используются для учета не являются унылыми по вашему мнению?
Я думаю это вы слабо представляете работу программиста.
Краткий экскурс. Программисты обычно характеризуются не только языком программирования но и областью в которой занимаются.
Так на С можно писать текстовые редакторы и 3Д игры.
Кстати даже в 3Д играх есть разделение, на тех кто пишет физику, тех кто работает с графикой, анимацией, карты генерирует.
Так вот если вы программист на С (и Си подобных языках) и постоянно пишете часть движка для игры в которой ваши модули отвечают за физику в мире игры. То со временем ваши знания относительно других «алгоритмов» атрофируются за ненадобностью.
1С — это частный пример. Вакансий в периферийных городах — достаточно в отличие от вакансий программистов на других языках.
1. размер базы или размер папочки с базой где лежит еще и лог транзакций?
2. Кроме статичных данных возможно хранились и другие? отчисления, оплаты и прочее. Всегда ведь можно зайти в базу и посмотреть какая таблица занимает сколько места. Вряд ли просто справочники весили столько.
Согласен конкурентов практически нет.
Есть только небольшие кустарные поделки которые либо помогают вести учет у ИП/ООО на упрощенке.
Либо местечковые варианты которые подходят только для конкретной фирмы.
Если углубляться в учет с НДС, учет по партиям, учет себестоимости комплектов и т.д. то вариантов не остается.
Всегда радовала позиция коментаторов 1С по поводу языка.
И все пишут именно про русский, хотя есть возможность использовать и другие языки. К примеру украинский. При разработке конфигурации с нуля, программист может создавать свой шедевр на том языке на котором хочет. Придираться к тому что создали другие и на каком языке — лишнее. Возьмите и напишите учетную систему с двумя планами счетов. И чтобы в коде было понятно что это за счет/субсчет/субконто.
И в полях которые будете показывать пользователю придется все предварительно переименовывать. Ведь он возможно захочет отсортировать отчет по каким либо фильтрам/критериям.
А затем вы решите распространять и поддерживать вашу конфигурацию. И попадутся внедренцы которые не владеют иностранным. И им не знакомы слова контрагент или оборотно-сальдовая ведомость написанные на английском языке. Время и сложность сопровождения вырастет в разы.
Вы возможно в языке программирования видите только логику работы программы. Дело в том, что 1С полноценная СУБД. В которой надо оперировать еще и методаби/объектами того учета в какой сфере используется конфигурация. Придумывать перевод для каждого начисления в ПФР очень сложно и муторно, а возможно и аналогов то нет на английском. Писать транслитерацией прикажете?
Ни одного плюса от использования латиницы нет. Сложная/дорогая поддержка. Не возможность перевести некоторую часть понятий. Это лишь два огромных минуса которые перечеркнут весь плюс от того, что на латинице букв напечатается чуть меньше.
Мало того что конструктор удобный, кроме этого очень удобная система работы с результатами запроса и визуализацией их на экране.
Притом эти запросы (уже можно говорить отчеты) перестраивает и настраивает сам пользователь. Сам настраивает группировки и последовательности строк. Что тоже довольно удобно.
Согласен что «свои нетленки» всеже стоит разрабатывать, только вилку цен я бы раздвинул в сторону понижения.
Согласитесь что для мелкой фирмы, которой нужен от типовой функционал толька штучного учета без партий, но с дополнительными разрезами будет накладно платить 300 000. За конфигурацию с 10 справочниками 5 документами и 5 отчетами стоит брать и поменьше.
Другой вопрос стоит связываться с таким маленькими организациями. Но это уже личное дело каждого.
Порог вхождения в сферу 1С ниже чем порог вхождения программистам на Java или C# (мое личное мнение)
Среда разработки в 1с меняется очень медленно. Я иногда пользуюсь Visual Studio .Net и это разительное отличие меня всегда смущает. Конечно по сравнению с другими средами разработки 1С отстает очень сильно.
Торговое оборудование, с COM и Lan портами — это скорее к производителям. Сейчас Китай наконец-то выпускает термопринтеры сразу с несколькими интерфейсами подключения.
Я писал что для большинства торгового оборудования есть уже написанные обработки для подключения их к конфигурациям. Для своих конфигураций (как впрочем и для СПО) приходится пользоваться только API драйвера который поставляет производитель оборудования.
По поводу любых программ — к сожалению сложно комментировать, т.к. те программы которые мне лично попадались имели либо ограниченный функционал по подключению внешних обработок, либо не имели его вовсе.
Цель любой коммерческой организации — получение прибыли. Это написано в ее уставе. Но поддерживать целый ворох разношерстных конфигураций, обновлять их в зависимости от изменения законодательства — это довольно трудоемкая задача. Я не хочу оправдывать нерасторопность развития платформы, но как мы видим конкурентов в сегменте среднего и малого бизнеса — нет.
Согласен что добавить какое-то значение или пачку данных для получения дополнительного функционала — это во внешние обработки не вытащить (ну или очень криво получится, к примеру хранить все данные во внешних таблицах скула и во внешней обработке сделать форму списка номенклатуры которая при выборе элемента будет искать дополнительные данные (картинки, описания и прочее) в других системах хранения данных), но это очень криво и непрактично.
Но вот именно само обновление конфигурации а равно как и платформы делать постоянно не стоит. На той же 7.7 работают много лет. И нет смысла что-то менять.
Бухгалтерия — это святое, и ее стараются не дописывать. А вот ТиС и УТ бывают сами на себя не похожи. И работают не один десяток лет.
1. Ну вопрос патчей — здесь не обсуждается, скажу что многие покупают и патчат по сей день
2. Таких организаций достаточно много. Для примера могу сказать что количество организаций сидящих на Торговля и склад 7.7 (ТиС) достаточно велико, и их переписывают с потрохами. Но реально смысла в обновлении ооочень мало. Если не сложно приведите 2-3 примера когда обновления (ежемесячные) необходимы.
3. Запросто можно написать внешнюю обработку и вызывать ее в нужном месте. Внешние отчеты\обработк\печформы, они привязываются в документам/справочникам, и их можно достать всегда и везде.
Я такими же аргументами оперировал когда в организации где я работал хотели создать свою CRM. Программист на РНР предлагал связку РНР + Apache.
Но после того как посчитали количество часов которое потребуется для того чтобы просто создать справочник контрагентов + некий документ заявка в котором будет использоваться еще несколько справочников то решили что 1С предпочтительнее.
1С позволяет не думать о хранении и взаимодействии данных и полностью сосредоточится на конечном результате. Конечно если мы пишем для крупных организаций с документооборотом по сотне тысяч строк в сутки и о сотнях пользователей в базе — тогда стоит правильно строить архитектуру чтобы в запросах не использовать получение данных через точку и на долго не блокировать таблицы констант (и прочие)
В самом начале даже писал на английском (еще на 7.7) но это быстро прошло.
Как пишется логика-не важно. Но вот доступ к данным — это уже другое и переключать раскладку ради If или For уже лишнее )
Это созданная СУБД с таблицами и связками. Если хотите получить только код и взвесить его выгрузите .cf файл. Это и будет чисто код без БД и прочего.
Если не секрет по каким меркам продукт унылый, и какие современные программные продукты которые используются для учета не являются унылыми по вашему мнению?
Краткий экскурс. Программисты обычно характеризуются не только языком программирования но и областью в которой занимаются.
Так на С можно писать текстовые редакторы и 3Д игры.
Кстати даже в 3Д играх есть разделение, на тех кто пишет физику, тех кто работает с графикой, анимацией, карты генерирует.
Так вот если вы программист на С (и Си подобных языках) и постоянно пишете часть движка для игры в которой ваши модули отвечают за физику в мире игры. То со временем ваши знания относительно других «алгоритмов» атрофируются за ненадобностью.
1С — это частный пример. Вакансий в периферийных городах — достаточно в отличие от вакансий программистов на других языках.
2. Кроме статичных данных возможно хранились и другие? отчисления, оплаты и прочее. Всегда ведь можно зайти в базу и посмотреть какая таблица занимает сколько места. Вряд ли просто справочники весили столько.
Есть только небольшие кустарные поделки которые либо помогают вести учет у ИП/ООО на упрощенке.
Либо местечковые варианты которые подходят только для конкретной фирмы.
Если углубляться в учет с НДС, учет по партиям, учет себестоимости комплектов и т.д. то вариантов не остается.
И все пишут именно про русский, хотя есть возможность использовать и другие языки. К примеру украинский. При разработке конфигурации с нуля, программист может создавать свой шедевр на том языке на котором хочет. Придираться к тому что создали другие и на каком языке — лишнее. Возьмите и напишите учетную систему с двумя планами счетов. И чтобы в коде было понятно что это за счет/субсчет/субконто.
И в полях которые будете показывать пользователю придется все предварительно переименовывать. Ведь он возможно захочет отсортировать отчет по каким либо фильтрам/критериям.
А затем вы решите распространять и поддерживать вашу конфигурацию. И попадутся внедренцы которые не владеют иностранным. И им не знакомы слова контрагент или оборотно-сальдовая ведомость написанные на английском языке. Время и сложность сопровождения вырастет в разы.
Вы возможно в языке программирования видите только логику работы программы. Дело в том, что 1С полноценная СУБД. В которой надо оперировать еще и методаби/объектами того учета в какой сфере используется конфигурация. Придумывать перевод для каждого начисления в ПФР очень сложно и муторно, а возможно и аналогов то нет на английском. Писать транслитерацией прикажете?
Ни одного плюса от использования латиницы нет. Сложная/дорогая поддержка. Не возможность перевести некоторую часть понятий. Это лишь два огромных минуса которые перечеркнут весь плюс от того, что на латинице букв напечатается чуть меньше.
Притом эти запросы (уже можно говорить отчеты) перестраивает и настраивает сам пользователь. Сам настраивает группировки и последовательности строк. Что тоже довольно удобно.
Согласитесь что для мелкой фирмы, которой нужен от типовой функционал толька штучного учета без партий, но с дополнительными разрезами будет накладно платить 300 000. За конфигурацию с 10 справочниками 5 документами и 5 отчетами стоит брать и поменьше.
Другой вопрос стоит связываться с таким маленькими организациями. Но это уже личное дело каждого.
Просто прям ножом по сердцу ) Вот и понесло.
Среда разработки в 1с меняется очень медленно. Я иногда пользуюсь Visual Studio .Net и это разительное отличие меня всегда смущает. Конечно по сравнению с другими средами разработки 1С отстает очень сильно.
Торговое оборудование, с COM и Lan портами — это скорее к производителям. Сейчас Китай наконец-то выпускает термопринтеры сразу с несколькими интерфейсами подключения.
Я писал что для большинства торгового оборудования есть уже написанные обработки для подключения их к конфигурациям. Для своих конфигураций (как впрочем и для СПО) приходится пользоваться только API драйвера который поставляет производитель оборудования.
По поводу любых программ — к сожалению сложно комментировать, т.к. те программы которые мне лично попадались имели либо ограниченный функционал по подключению внешних обработок, либо не имели его вовсе.
Цель любой коммерческой организации — получение прибыли. Это написано в ее уставе. Но поддерживать целый ворох разношерстных конфигураций, обновлять их в зависимости от изменения законодательства — это довольно трудоемкая задача. Я не хочу оправдывать нерасторопность развития платформы, но как мы видим конкурентов в сегменте среднего и малого бизнеса — нет.
Но вот именно само обновление конфигурации а равно как и платформы делать постоянно не стоит. На той же 7.7 работают много лет. И нет смысла что-то менять.
Бухгалтерия — это святое, и ее стараются не дописывать. А вот ТиС и УТ бывают сами на себя не похожи. И работают не один десяток лет.
2. Таких организаций достаточно много. Для примера могу сказать что количество организаций сидящих на Торговля и склад 7.7 (ТиС) достаточно велико, и их переписывают с потрохами. Но реально смысла в обновлении ооочень мало. Если не сложно приведите 2-3 примера когда обновления (ежемесячные) необходимы.
3. Запросто можно написать внешнюю обработку и вызывать ее в нужном месте. Внешние отчеты\обработк\печформы, они привязываются в документам/справочникам, и их можно достать всегда и везде.