Комментарии 345
Разработка бизнес-приложений и тем более, например разработка и внедрение систем класса ERP
Ну а в том сегменте у них крепко сидят QuickBooks и BusinessCentral. И они могут предложить киллер-фичу, которой нет у 1С: вы можете купить QuickBooks и начать работать, без разработки бизнес-приложений, и тем более, разработки и внедрения ERP.
Более того, малому и среднему бизнесу вообще в массе своей противопоказана разработка чего-либо, только приобретение готового коробочного решения.
Более того, малому и среднему бизнесу вообще в массе своей противопоказана разработка чего-либо, только приобретение готового коробочного решения.Эх, ваши бы слова… Почему-то именно малый бизнес наиболее изворотлив в изобретении хитрых схем, которые ни на одно коробочное решение не ложатся.
в US учет другой, бухгалтерия проще и без извратов — для мелких вообще не регулируется, просто плати налоги и храни отчетность 5 лет.
Покидал в коробку и поставил в бейсмент.
Остальное на твое усмотрение вообще как угодно. Массовые сверх-хитрые сценарии никому не нужны.
Фокусы и схемы начинают когда деньги большие и бизнес публичный (акционированный) и следовательно формальная отчетность.
ну а есть объяснения отчего SAP и прочие ино-монстры у которых технологий попой кушай — не взлетели толком в России. И уйма других бизнес приложений, вполне успешных.
И Майкрософт когда то с MS-Money выходила и еще кто то.
Надо полагать, они поменяли свои бизнес процессы под западные.
Врядли в штатах станут так поступать.
А не взлетело у малого потому, что при заходе на российский рынок стоили они ОЧЕНЬ дорого, а готовых тиражных конфигураций не было как класса.
Смутно представляю что такое нонче 1C. Речь о другом.
Только кажется что все готовы покупать продвинутые решения. Тем более свой макроязык? А идея продавать пирожки там, а печь в России аутсорсом, копируя индусов — сомнительна. Русские не индусы.
Все рестораторы из России быстро обломались в штатах. Хотя казалось бы — и опыт и деньги есть, что вообще такое сложное — ресторан.
Но что то продать можно, безусловно.
Или вы всерьёз считаете, что в 1С работают идиоты,
Я так не считаю. Хотя мой опыт пасения аутсорсеров/девелоперов и соответственно общения с отдельными людьми и командами с xUSSR не шибко положительный и иногда даже мне было ммм… необычно до предела.
Почему-то именно малый бизнес наиболее изворотлив в изобретении хитрых схем, которые ни на одно коробочное решение не ложатся.
Это же про малый бизнес в странах СНГ и им подобным. В США малому бизнесу не нужно вести налоговый учёт, вести отдельно продажи «вне кассы» и аналогичные закупки, синхронизировать между собой белые/серые остатки и так далее.
вести отдельно продажи «вне кассы» и аналогичные закупки, синхронизировать между собой белые/серые остатки и так далее.
и почему наш бизнес вынужден так делать?
А вот если бы ВСЕ платили налоги и работали в белую, сильно хуже от этого бы не было
налоговые инспекторы в общем-то про них в курсе, но закрывают глаза (не бесплатно)
ну они и бесплатно глаза закрывают
Открывается новое ООО, мораторий на проведение проверок 3 года — поддержка бизнеса!.. левачат, чернушат, черти что делают… через 3 года закрывают, открывают новое — повторяют по кругу.
и очень от многих я слышал фразу «государство знает что нам тяжело, по этому позволяет так левачить» (с)
Высокая налоговая нагрузка для дефолтных белых схем, относительная легальность серых.
а по нагрузке — это следствие того что народ хочет без фин.расчетов заниматься бизнесом и страшно удивляется что это не приносит денег
Ну, я сталкивался с вариантом: считают бизнес-план на ОСНО, не понимают как конкруенты умудряются что-то зарабатывать, изучают вопрос и приходят к выводу о неизбежности хотя бы серых схем.
тем более, например разработка и внедрение систем класса ERP
Вы так говорите, как будто в Штатах на рынке ERP пусто.
Общий посыл от этого не меняется: на рынке ERP в США уже достаточно тесно. Что 1С может предложить такого, чтобы выглядеть лучше существующих игроков?
Заметим сразу, что недостаток у предлагаемой вами схемы есть — скорость поставки решения, и особенно внесения небольших доработок намного ниже по сравнению с ситуацией, когда разработчики сидят в Штатах.
Заметим сразу, что недостаток у предлагаемой вами схемы есть — скорость поставки решения, и особенно внесения небольших доработок намного ниже по сравнению с ситуацией, когда разработчики сидят в Штатах
Да, согласен, близость к Заказчику — важный фактор, при этом «разработчики сидя» и «близость к заказчику» — как раз то, на чем я делаю акцент. Я предлагаю быть близко к Заказчику, при этом разработку вести в другом месте (на самом деле, даже в Штатах так и есть, с Заказчиком общается не кодер, а консультант\РП-ик). Единственное, очень не хватает инструменты быстрого прототипирования (UI\UX без кодинга), силами консультанта.
Я предлагаю быть близко к Заказчику, при этом разработку вести в другом месте
Это будет дольше, чем если бы разработка велась в том же месте, и, как следствие, вы будете проигрывать тем конкурентам, которые могут легко позвать на встречу с заказчиком разработчика, чтобы все обсудить без лишних задержек.
мы же привыкаем сейчас все делать на удаленке
Извините за прямоту, судя по этой фразе, вы даже еще не успели понять, в чем будут проблемы.
эти «потери» можно компенсировать иным.
Можно. Мой пойнт именно в том, что вам понадобится их компенсировать — т.е. тратить ресурсы на то, чтобы быть на том же уровне привлекательности, что и конкурент, у которого этих потерь просто нет.
даже еще не успели понять, в чем будут проблемы.
Не правы, лишь придерживаюсь контекста исходного диалога, если еще начнем обсуждать чем закончится, то комменты ни когда не закончатся.
тратить ресурсы на то, чтобы быть на том же уровне привлекательности, что и конкурент, у которого этих потерь просто нет.
я согласен, другими словами, но еще раньше об этом сказал- что согласен. При всех прочих равных, конечно выиграет тот, кто ближе, НО одинаковых команд не бывает, у всех есть свои сильные и слабы стороны. Статья, в том числе, затрагивает тему того, что вендор не учитывает свои «минусы» на внешнем рынке, а если бы еще точнее, не старается их компенсировать за счет создания лучших условий и\или смены модели для своих партнеров.
При всех прочих равных, конечно выиграет тот, кто ближе, НО одинаковых команд не бывает, у всех есть свои сильные и слабы стороны.
Ну, я собственно и спросил, в чем же сильные стороны-то?
Пока же 1С только лицом к разработчикам повернулась в полоборота, вон async await в язык завезли
Считать, что эта невероятная шляпа 1С со своими решениями может представлять интерес для SMB (small & medium business) сегмента за пределами России может только тот, кто никогда не работал с зарубежными заказчиками из сегментами и с инструментами для автоматизации и бизнес логики, используемыми там.
Сравнивая подобные инструменты убожество 1С просто поражает.
В США рынок столь огромный, что даже такую шляпу как 1С можно продать несчастным. Тем более если у них русскоговорящие корни.
С кем сравнивать намеренно говорить не буду — изучайте рынок самостоятельно. Смайликов и улыбочек нет.
И мне очень жаль, что множество бизнесов в России завязано на эту лживую и убогую платформу, создатели которой несколько дней назад ещё и пытались выпросить денег из бюджета России, то есть моих налогов.
В США рынок столь огромный, что даже такую шляпу как 1С можно продать несчастным. Тем более если у них русскоговорящие корни.
Как раз таки — нет, самые, что не наесть аутентичные корни, которые в РФ открыли филиал и буду в будущем локализовывать производство. Делали легкое решение, для формирования документов, связанных с Cargo.
лживую и убогую платформу
В чем лживость и убогость, что заставляет выражаться в столь агрессивной манере?
Именно из-за низкого порога входа она кажется убогостью.а это уже как каждый видит. Как говорится, «когда на западет такое — это защита национальных интересов, а когда у нас — ущемление прав и свобод...»
Это и сила и слабость, вопрос в регулировании\управление этим.
Сейчас много что изменилось. В любом случае, не ошибается тот, кто ничего не делает,1с при всех проблемах и недостатках — отечественная система и стоит не просто хейтить, а указывать на проблемы, предлагать решения и вносить свой позитивный вклад.
1с при всех проблемах и недостатках — отечественная система и стоит не просто хейтить, а указывать на проблемы, предлагать решения и вносить свой позитивный вклад.
А, простите за прямоту, зачем?
Так вот рынок решил что лучше получилось у 1С, а вы почему то с этим спорите, что якобы тут «крайне удачная модель продаж»
Я с этим не спорю. Крайне удачная модель продаж — это тоже рыночное преимущество, очень сильное.
Мне лично хотелось бы чтобы 1С развивался дальше, потому что она действительно приносит много пользы бизнесу, почему бы не помочь компании развивать продукт, чтобы он ещё больше приносил пользы
О, божечки. Помогите лучше АвтоВАЗу, а то у Лады Весты краска на бампере в первый же год начинает облезать. А лучше купите игрушек в ближайший детдом. Тоже мне, блин, нашли себе проблему, за которую якобы надо беспокоиться.
Мне вот очень интересно, как вы от "я не хочу кому-то помогать" переходите к "я против". Это как бы не одно и то же, вообще никак.
Я правильно понимаю, что вы помогаете всему, что разработано и произведено в России?
а) не люблю некачественные вещи.
б) не болен патриотизмом головного мозга, и надпись «сделано в России» на бирке к товару не вызывает у меня избыточного прилива адреналина и желания купить его именно по этому признаку, и уж тем более бросаться поддерживать его производителя.
На мой взгляд 1С вообще не уделяет внимание рекламе, наверное просто потому что у нее нет конкурентов.
чтобы продукт развивался
А зачем мне это?
приносил больше пользы
Кому? Мне? Я им не пользуюсь.
вы против этого?
Нет, я не против этого как чего-то, что происходит без моего участия. Но я совершенно не понимаю, почему мне стоит предлагать какие-то решения и вносить позитивный вклад.
софт много где используется, цена ниже западных аналогов, а значит ниже влияние на себестоимость товаров\услуг
И что? Что, от того, что я "внесу позитивный вклад", это влияние станет еще ниже?
С этой точки зрения намного выгоднее нести свой позитивный вклад в сторону бесплатного ПО, например.
И сейчас эти же бесплатники начнут платить за то, что благодаря им и создано.
Бесплатный сыр только…
Подождите, ну так предлагаемый вами "позитивный вклад" — это и есть бесплатный сыр. Просто для 1С, а не для пользователя.
Ща Micrisoft гайки закрутит, более того, уже заработать успела на «бесплатниках»
Мне кажется, вы что-то путаете.
это и есть бесплатный сыр. Просто для 1С, а не для пользователя.
Отнюдь.
Мне кажется, вы что-то путаете.
Свяжите факты:
Шаг 1: Git — бесплатный
Шаг 2: Продается Micr
Шаг 3: Начинается монетизация
Шаг 4: Выпускает решение по анализу кода, ведь глобальная база всевозможного кода — исходного материала, уже есть
Отнюдь
Аргументируйте. Почему это не бесплатный сыр?
Свяжите факты:
Это не факты. Это ваше представление о происходящем.
Шаг 1: Git — бесплатный
А зачем вы путаете git и GitHub?
Начинается монетизация
То есть вы не в курсе, что у GitHub была монетизация до их покупки MS?
Выпускает решение по анализу кода
То есть вы не в курсе, что это решение было и раньше?
глобальная база всевозможного кода — исходного материала, уже есть
То есть вы не в курсе, что эта база была (и сканировалась) и раньше?
p.s. и справедливости ради, на какомнить SAP проблемы недостаточности функционала и API решались так
1) нам нужна фича _такаято_
2) запросто, ценник 100500$ плюс команда консультантов за 200500$ плюс поддержка того что вышло 300500$
3) нам не нужна фича, в экселе перебъемся
4)…
5)… какой кривой 1С… постоянно там чтото доделывают, допиливают, ничего там нет, надо всё дописывать… а вот САП какой замечательный! ничего дорабатывать не надо!
вы скорее устаревшую версию использовали (многие упоротые 1С-ники до сих пор 8.2 таскают, со словами «зачем обновлять, если работает»)
5 лет назад нормального инструментария для REST у 1С не было и не могло быть. Соединение поднималось со всем окружением секунды 2. JSON из коробки не было.
wonderland.v8.1c.ru/blog/sredstva-raboty-s-json
статья 2014 года, версия которая там указана вышла в середине 2015 года (судя по всему её дописали в статью позже)
Если говорить про интерфейс, это особая боль, можно проводить уроки UI/UX как НЕ надо делать.
интересный тезис. Можете в личку написать примеры конкретных моментов, как не надо делать. Можно на примере этой демо-базы: unf.demo.1c.ru/unf/ru_RU
Буду искренне очень благодарен за 5-6 примеров! Серьезно, очень хочу услышать мнение не 1С-ка!
Про интерфейс, нужно давать уроки всем, даже спецам майкрософта, гугла, телеграмма, 90% дизайнерам сайтов.
Если вы не смогли что то написать на 1С (о боже, это же бейсик), то это говорит только о вашем уровне, либо о том что вы знаете другой язык и все. И скорее всего все что вы написали на другом языке, было бы намного быстрее и удобнее написать на 1С.
Так что есть куда стремиться.
и в итоге выдал звуковой сигнал, означающий, что остатков нет.
А вы думаете, в этом SAP виновата? Она якобы остатки считать не умеет? :)
Кривое решение на 1С — виновата 1С
Кривое решение на SAP — виноваты местные криворукие интеграторы, но не SAP
1. Профессиональный внедренец
2. Профессиональный руководитель проекта со стороны заказчика
3. Достаточные полномочия у этого РП, чтобы убедить/мотивировать/заставить всех участников проекта выполнять то, что было задумано разработчиками бизнес-процессов.
Даже при условии наличия п.1 (что далеко не всегда, к сожалению), в крупных компаниях зачастую наблюдается проблема с п.3, а в мелких — с п.2. Но проблема п.3 хотя бы решается при желании. п.2 — никак
Почему убожество? Платформа отличная, нет только решений готовых на нем для МСБ США.
Люди заражаются и помирают, а 1С на этом пиар пилит. Ну хотя я всегда знал, что конторка гавнистенькая.
1С завоюет мир когда русский язык станет общим и единственным в мире, не раньше
А интерфейс можно делать на любом из множества поддерживаемых языков.
Если с нуля писать конфигурации, то, может быть. Но, емнип, очень много вещей в конфигурациях именуются исключительно на ломаном русском и код получается как смесь английского и русского. По крайней мере по пмяти о 7.* дело обстояло так. Сначала писал на английском код, но потом таки переш'л на русский — меньше глаза стали дергаться
Объясняю, «ящик с инструментами от 1С» предназначен для автоматизации учетных задач
«Предназначен для автоматизации учётных задач» должно подразумевать, что там есть что-то готовое для автоматизации учётных задач, чего нет в других аналогичных наборах инструментов. Вот скажите мне, что я могу взять готовое в 1С при создании новой информационной базы, что мне упростит решение моей некоей учётной задачи?
Уверен, что где-то такие есть, но в РФ я с таким не сталкивался
Ну так в РФ, минуточку, изначально рынок под 1С подмят.
Ну так в РФ, минуточку, изначально рынок под 1С подмят.
каким же образом?
Встроенную в платформу объектную модель — регистры бухгалтерии, регистры расчеты, регистры накоплений, планы счетов и тд
Согласен, ну тут есть два больших «но»:
1. Реализовать собственно план счетов и бухгалтерские регистры на любой другой платформе, где их нет, это 1% от общего объема работ, и ценность этого не особо велика, и с лихвой перекрывается, например, удобством разработки.
2. Всё это пригодится только для узкого класса задач — автоматизации бухгалтерского учёта. Т.е. не пригодится для подавляющего большинства мелкого бизнеса, и для многих предприятий среднего бизнеса на Западе.
1. Не будьте так уверены, что спроектировать базовый функционал для БУ/НУ учета это так просто
Я и не говорю этого. Просто в чистой базе 1С нет базового функционала для учёта, там просто темплейты для нескольких видов объектов — план счетов и регистры с субконто. Повторить это действительно просто. Здесь даже речь о проектировании не идёт, они во всех системах примерно одинаковые с незначительными вариациями, будь-то 1С или там Microsoft Dynamics 365. Если вам это в вашей системе надо, просто потратьте несколько часов, чтобы сделать такое же. Или Ctrl+C, Ctrl+V из вашего предыдущего проекта, если вы не первый раз в этом бизнесе.
1С во-первых предлагает богатый набор инструментария (какие хотите формочки клепайте, какие хотите таблицы и даже какую хотите интеграцию), а во вторых возможность найти студентов, которые смогут это освоить
И вот про это я и говорю — такое точно есть в любой среде разработки, во многих более удобное, более гибкое, более универсальное. И толковых студентов, которые учат С#, проще найти, чем толковых студентов, которые учат 1С. Тем более, на западном рынке, если уж мы говорим про него.
Я оставляю за кадром вопрос, через какое время студент, кастомизирующий учётную систему, похоронит верный учёт в компании. Но да, не способные оценить ИТ-скиллы боссы студентов на это нанимают, факт.
Мда… Я вижу, что вы вообще не имеете представление об этих механизмах в платформе 1С
А, ну да. Лучший способ уйти из беседы — сказать, что собеседник ничего не понимает, и сбежать ;)
На самом деле я написал как есть. 1С не предлагает ничего ценного для разработки решения с нуля. По крайней мере, такого, что бы компенсировало её недостатки.
А давайте вы поработаете с 1С хотя бы несколько лет,
Эээ, спасибо, но нет. Я как-нибудь уж так обойдусь.
насмотритесь на все подводные камни, которые попадаются при автоматизации учета,
За 20 лет такого насмотрелся, что вам и не снилось.
увидите как оптимально 1С эти проблемы решила за счет базовых механизмом платформы
Ну вот например? Раз вы заявляете, давайте, раскройте свою мысль. У вас же есть хоть один пример, за эти несколько лет, верно ведь? ;)
Вы ещё до налоговых разниц
Так, так, ну расскажите поподробнее, как 1С в чистой информационной базе будет считать налоговые разницы?
сотен миллионов проводок не дошли и как по ним формируются агрегированные итоги
А, ну извините. Я просто не знал, что вы не в курсе, как делать агрегированные итоги. Что для вас это тоже магия, требующая много усилий.
но оно уже есть искаропки.
Чтобы быстро реализовать итоги, нужно на финжурнал повесить триггеры на вставку/удаление/обновление, которые будут обновлять соответствующее значение в таблице итогов. Таблица итогов по периодам нужна всего одна на каждый журнал. Имеет подобную ему структуру.
Вы за деревьями не видите леса. Чтобы получить нужный бизнесу результат, совсем не обязательно тщательно и в деталях повторять всю ту кучу барахла, которую за 30 лет несёт в себе 1С.
с бухитогами по субконто — не совсем.
Чтобы получить нужный бизнесу результат— вы знаете все существующие бизнесы? или нужный одному конкретному бизнесу, который знаком именно вам?
Ну и опять же, зачем изобретать велосиепд и копипастить механизм виртуальных таблиц из проекта в проект — если 1с в коробке имеет виртуальные таблицы. (и опять же, почему-то 1с не имеет механизма нарастающих итогов, которые все 1сники копипастят)
на финжурнал повесить триггеры— а они во всех СУБД, с которыми ваш софт будет работать, одинаковы? а разворачиваются — автоматически? в общем, если вы реализуете (а оно вполне реализуемо) все возможности 1с — вы и получите примерно то же самое. Да, без легаси. но в 22 веке.
— вы знаете все существующие бизнесы? или нужный одному конкретному бизнесу, который знаком именно вам?
Все эти нестандартные потребности бизнеса в массе своей лежат далеко за тем, что может предложить любая типовая платформа. Учесть одну операцию — это у всех примерно одинаково. Посчитать итог в разрезе какого-либо измерения — у всех примерно одинаково. Сложности начинаются, когда надо консолидировать учёт из разных источников, когда надо выявлять расхождения, когда надо какие-то хитрые бизнес-процессы автоматизировать. Так или иначе, платформа в этом вам не помощник, здесь мозги нужны.
— а они во всех СУБД, с которыми ваш софт будет работать, одинаковы? а разворачиваются — автоматически?
А это неважно. Триггером может быть совсем не обязательно объект в СУБД. Это может делать и ваш ORM. Мы же не про конкретную реализацию говорим, а в общем, про относительную простоту этого механизма, что он не является какой-то там супермагией.
в общем, про относительную простоту этого механизма, что он не является какой-то там супермагией.
так нет ничего супермагического. Вон, 1с++ для клюшек написали совсем не нургалиевцы.
но дело в том, что если вы напишете реализацию, отвечающую требованиям, с которыми сталкивается 1с — вы получите что-то близкое к реализации 1с. Либо получите гораздо более крутое (быстрое, менее голодное), но более частное решение.
Опять же, если расширять/дорабатывать решение, а вы тут решили внезапно… ну этта, короновирус, да… у вас все настолько задокументировано, что ваш преемник слёту в курс дела? Нет, «тут мозги нужны», и желательно хорошие, дорогие? а бизнесу что лучше?
Ну и опять же, зачем изобретать велосиепд и копипастить механизм виртуальных таблиц из проекта в проект
А вот тут вопрос, нужны ли эти виртуальные таблицы.
нужны ли эти виртуальные таблицы.
Да не обязательно. можно и к реальным таблицам запросы делать. можно обходиться без таблиц итогов. можно обходиться без триггеров. можно и без SQL обойтись, и даже без СУБД…
Вообще без компьютеров («компьютеры коммерсанты придумали, чтоб налоговую обманывать»©1996, начальник налоговой инспекции )
но зачем изобретать велосипед с колесами разной степени угловатости?
Не, я и напрямую с ДБФ работал, уж не помню занафига такой изврат нужен был. Но лучше все-таки штатными средствами.
Да, писал дизассемблер и ассемблер на 7.7 — но это было больше в качестве развлекухи.
Я не удивлюсь, если в .net есть готовая библиотека с таким функционалом. Ну и чем это по большому счету отличается от 1с?
и в 1с, и в других фреймворках есть свои преимущества и недостатки. я б уж так беспочвенно не поливал бы 1с известной субстанцией. Хотя ее поделки порой реально бесят, я даже не представляю, под какими веществами там проектируют и пишут…
но не забывайте что субконто имеют разные типы — это разные таблицы
А с точки зрения разработчика стороннего решения, не на базе 1С, все субконто скорее всего будут иметь один тип — код бизнес-сущности для соответствующей аналитики, будь-то филиал, бизнес-линия, контрагент и так далее. Нет практического смысла делать их разнородными.
Просто написать отчет выводящий остатки по счетам в разрезе субконто не получится
Но почему? Что мне в этом отчёте от субконто может понадобиться, кроме кода и наименования? Это совершенно однотипные данные, и для них не надо лезть в таблицы каждой сущности, их можно хранить как непосредственно в журнале, так и в отдельной связанной с ним таблице, если количество аналитик к счетам должно настраиваться произвольно без изменения структуры БД.
Такая таблица может иметь вид
— Код операции
— Вид субконто
— Значение субконто
— Описание
Ну и наполняться примерно так:
1 Товар ТОВ-00010 Собачий корм
1 Филиал МГТГ Магнитогорск
1 Бизнес-линия ПВК Продукты-вкусняшки
2 Товар ТОВ-00012 Верёвка с мылом
2 Филиал НУСТ Нижний Устюг
2 Бизнес-линия ТОБ Товары от безысходности
И так далее. Этого достаточно для построения аналитических отчётов без заглядывания в справочники
Для меня это не приемлемо, правила нормализации нарушаются.
Кстати, тоже немаловажный момент: нормализация — это инструмент обеспечения целостности данных, а не самоцель. В учёте, например, очень важно хранение исторических данных. Поэтому нормализация «в лоб» наоборот, может нарушать их целостность. Грубо говоря, если вы вчера продали ТОВ-00010 Собачий корм, а сегодня после переименования ТОВ-00010 Собачий корм Вискас, то как минимум, и старое, и новое название должно отразиться в операциях за соответствующие даты, вне зависимости от того, как там его на текущий момент переименовал товаровед. Естественно, в зависимости от пожеланий заказчика могут быть разные варианты, но тут общего решения как раз и нет. В бухгалтерской истории операций — практически всегда нужно видеть как раз историческое название. А вот если это, например, данные по маркетинговой аналитике, то тут могут быть варианты. Чаще нужно видеть одно актуальное наименование, но если переименование было частью каких-либо преобразований в бизнесе, то маркетолога будет интересовать и старые данные, и новые, раздельно.
Поэтому, повторюсь, тут нет явного общего решения.
Грубо говоря, если вы вчера продали ТОВ-00010 Собачий корм, а сегодня после переименования ТОВ-00010 Собачий корм Вискас
Так с точки зрения бухучета и документооборота — это разные товарные позиции, они не должны переименовываться
тоесть если к вам на склад по документам пришел сегодня Собачий корм, а завтра Собачий Корм Вискас… вы не можете его оприходовать на один и тотже товар… даже если коробка похожа и вообще это фактически тоже самое.
Первичен — документ и что там написано
p.s. а следующим шагом будет то что цены на приход товара — разные… и надо учитывать партии чтобы правильно считать себестоимость
Так с точки зрения бухучета и документооборота — это разные товарные позиции, они не должны переименовываться
В том-то и дело, что в общем случае одинаковые. Разные — только если артикул поменялся.
p.s. а следующим шагом будет то что цены на приход товара — разные… и надо учитывать партии чтобы правильно считать себестоимость
Ну, да. Хотя мелкий бизнес зачастую нормально обходится и без партионного учёта.
С точки зрения бухучета — при соотвествующей политике вы вообще можете учитывать поступающие «собачий корм вискас» и «кошачий корм педигри» как «корм для животных».
Правда, и продавать вы тогда будете «корм для животных».
Для каких задач использовать ящик от Майкрософт я не знаю, но на данный момент не сталкивался с системами бухгалтерского, налогового учета и расчета ЗП, которые были разработаны на базе инструментов из ящика от Майкрософт
Эмм. Вы про Microsoft Dynamics никогда не слышали?
(и это, как бы, не единственная)
Во-первых, "слышали, даже работали" плохо сочетается с "не сталкивался с системами".
А во-вторых, пост — он как раз про "за пределами российского учета". Не говоря уже о том, что в .net нет ничего такого, что технологически мешало бы его использовать для российского учета.
Принцип был похожий, тематические конфигурации, поддержка в соответствии с изменениями законодательства и так далее. Разница только в бизнес-подходе (вот ответ, почему именно 1С) — если 1С развели армию партнёров-франчайзи в каждой подворотне, эти пытались продавать сами. Поэтому и уступили рынок. Софтина, кстати, до сих пор жива, называется Акцент-бухгалтерия.
Так вот, к чему это я? К тому, что без разницы, какой ящик инструментов использовать, если он позволяет писать нужный вам софт. Эта вот Акцент-Бухгалтерия была написана целиком на VBA MS Access.
Никто насильно не заставлял открывать тысячи франчей.
Почему насильно? Это просто был прямой и дешёвый способ войтиВайти, с минимальными вложениями. Свой продукт не нужен, мощная рекламная и информационная поддержка есть, норма прибыли хорошая. Вкусно. Вот и набрались франчи.
1С победила не функционалом, не технологичностью. Она победила крайне удачной моделью продаж.
Там, где они предлагают функциональность, которой нет у SAP/SF, более дешевое или простое внедрение, клиентоориентированность и так далее.
Т.е., надо четко понимать, что ответить на вопрос клиента, которому ты пришел продавать "конкурента SAP", "а почему я должен работать с вами, а не с SAP".
Какие вопросы у Вас по лицензированию возникли? Возможно у меня получится дать Вам ответ на них.
Понимаю ваше негодования, за время работы в 1С франчайзи столкнулся с большим числом некомпетентных специалистов в этой области. Но, если говорить откровенно, я встречал среди клиентов и некомпетентных системных администраторов также.
К слову сказать одна из причин моего ухода из 1С является наплевательское отношение к разработке среди разработчиков и нежелание учиться.
Почитал комментарии, исходная ниша 1C занята в штатах Intuit (TurboTax для физлиц, QuickBooks для учёта юрлиц), платформа для бизнес-приложений — Salesforce. Это если по верхам, конечно, так одних систем по начислению зарплаты (payroll) 100500, и много чего ещё есть. И так же, как успех 1С идёт от бухгалтерского учёта, успех TurboTax идёт от учёта налогового (притом для физлиц), который по сложности и масштабу соразмерен бухгалтерскому учету в России (тогда как для мелких фирм все действительно сильно проще). Это преимущество приобрести уже невозможно никому другому. А аутсорсеров хватает.
Turbotax есть и для бизнеса.
Есть peachtree, для разработки решений есть Microsoft Dynamics AX
что то делает оракл на определенных отраслей, ходовой payroll — ADP и так далее. Есть отдельно системы учета для, к примеру сдачи жилья в рент (это бизнес, часто с многими домами).
рынок отнюдь не пуст.
Но это не значит что в ём глухая стена.
https://1c-dn.com/ посмотрите
Все прилетит назад.
Тут свой монополист — Tally.
Отдыхайте
не будет модного и молодежного веб-интерфейса, зато будет тупая работоспособность.
Правда, получится как с КОБОЛом…
Делал генерацию хранимок — это тоже в некотором виде «серверные» (причем настолько серверные, что серверней уже некуда). фоновые —
не так давно писал некий аналог, «от нехрен делать и для развеяться», когда задолбало в этих перекидываниях между контекстами в восьмерке ковыряться. Специально у Садовникова исходники нетаинет просил.
Это не считая практически штатного решения шедулера — запуска по расписанию, отработавшего с 2005 года больше 12 лет…
На формексе для 7.7 даже аналог УФ делали (формы с декларативным описанием, хранящемся в базе). Ничего военного!©
Я вот честно говорю — даже не задумывался, сколько потребляли клюшки на клиентском месте. Всегда хватало, даже с учетом открытых у юзверя других приложений…
Правда, есть нюансы — пока делаешь хорошо и по уму, молодняк методом ХХП может уже сделать. Но тогда и удивляться распуханию не приходится…
по молодости-неопытности _мои_ сеансы, бывало, падали — но сами ж понимаете, в ТЗ можно пихать много… особенно если работа какая-нибудь разовая, типа переноса… лень оптимизировать, проще частями…
поэтому было решение перейти на типовое. Типовое — дохнет.
вот и весь баланс между кастомным и типовым.
Не, оно, конечно, работает… неспешно, вальяжно…
но там, где я описывал выше реализацию на клюшках — типовые УПП и УТ не взлетели (я к тому времени оттуда ушел, поэтому деталей сказать не могу. Так они и работали на 7.7 еще года 3-4, а потом возникли другие проблемы)…
Убивает метание между контекстами когда каждую строчку кода перекидывают как горячую картошку между клиентами и сервером
так в обычной разработке точно также, метание между фронтом и беком… только их разные люди делают — а тут один человек
Заминусовали человека почём зря. Ведь, по сути, 1С — это очень высокоуровневый и очень предметно-ориентированный фреймворк, эдакий конструктор LEGO на стероидах для построения учётных систем. И скорость традиционной разработки, по объективным причинам, не может быть быстрее по сравнению с конфигурированием 1С просто потому, что 1С-нику львиную часть работы просто не надо делать, т.к. за него это уже сделали разработчики платформы. Причем не только написали, но и собрали все грабли по пути и оттестировали. А 1С-разработчику остаётся крупными мазками, в терминах бизнес-сущностей "рисовать" бизнес-процессы.
И скорость традиционной разработки, по объективным причинам, не может быть быстрее по сравнению с конфигурированием 1С просто потому, что 1С-нику львиную часть работы просто не надо делать, т.к. за него это уже сделали разработчики платформы.
… это пока надо сделать то, на что разработчики платформы рассчитывали.
впрочем, на 1с писали покер-сапера-змейку, я ваял ассемблер-дизассембер для 51, люди делали управление складскими тележками-шаттлами, сейчас вижу, как нечто подобное MES-системе ваяют (соединение с чпу, не буду дальше их кухню раскрывать), всякие СУРВ и СКД. Если не хватает возможностей платформыы — есть совершенно штатные механизмы внешних компонент. Примерно как — недавно попадалось на хабре — интеграция кусков на с++ и питоне.
Но, естественно, лучше использовать 1с для того, для чего она предназначена: для учетных задач (не только бух и зп, но и оперативный учет и планирование во всех проявлениях).
Если не хватает возможностей платформыы — есть совершенно штатные механизмы внешних компонент. Примерно как — недавно попадалось на хабре — интеграция кусков на с++ и питоне.
Мне кажется, это прекрасная иллюстрация к "скорость традиционной разработки, по объективным причинам, не может быть быстрее по сравнению с конфигурированием 1С".
… что не очень понятно, зачем разрабатывать внешние компоненты, если сконфигурировать 1С, по объективным причинам, не медленнее. Из любви к искусству?
Например, штатно нет доступа к ком-порту — пришлось конфигурировать на дельфях. не было удобной работы с твайн средствами языка для сканирования документов — тоже пришлось конфигурировать на дельфи. То же самое — для связи с астериском.
Можете рассматривать внешние компоненты как существующие в других языках библиотеки.
кстати, на чем конфигурируете вы?
Затем, что у платформы может не существовать штатных методов.
Подождите, но как же "за него [1С-ника] это уже сделали разработчики платформы"?
Можете рассматривать внешние компоненты как существующие в других языках библиотеки.
Не, не могу. Потому что обычно я могу написать библиотеку для "другого языка" на том же самом языке. А если верить вашим примерам, нет никакого смысла писать "внешние компоненты" на 1С.
Подождите, но как же «за него [1С-ника] это уже сделали разработчики платформы»?
вы включаете дурака, или спрашиваете серьезно?
зачем тогда вообще кто-то что-то пишет, если в мире полно уже написанных программ?
Потому что обычно я могу написать библиотеку для «другого языка» на том же самом языке
а «необычно»?
ну вот два простых примера:
1)решение СЛАУ было написано «на языке платформы», но работало медленно. Пришлось разрабам встроить Решение СЛАУ в платформу, т.е. по сути, переписать его на другом языке. Но тем не менее, решение «на том же самом языке» существует. (это же касается и значительной части того, что я перечислил в числе внешних компонент.)
Да, напомню вопрос — вы на чем сами «конфигурируете»?
2)TensorFlow. Написана на Python, C++, CUDA. Основной API для работы с библиотекой реализован для Python, также существуют реализации для C Sharp, C++, Haskell, Java, Go и Swift.
почему никто не переписывает ее на «C Sharp, C++, Haskell, Java, Go и Swift.»?
вы включаете дурака, или спрашиваете серьезно?
Серьезно спрашиваю. Потому что я нахожу очень показательной ситуацию, когда сначала пишут "1С-разработчику остаётся крупными мазками, в терминах бизнес-сущностей "рисовать" бизнес-процессы", а потом добавляют "у платформы может не существовать штатных методов".
зачем тогда вообще кто-то что-то пишет, если в мире полно уже написанных программ?
По моим наблюдениям, в ощутимой доле случаев — из любви к процессу или из (часто ложного) убеждения, что могут сделать лучше.
а «необычно»?
А "необычно" от языка зависит.
Да, напомню вопрос — вы на чем сами «конфигурируете»?
Конфигурирую? На yaml обычно, если выбор есть.
TensorFlow
TensorFlow — это не совсем "существующая в других языках библиотека".
почему никто не переписывает ее на «C Sharp, C++, Haskell, Java, Go и Swift.»?
А зачем?
В контексте этого вопроса полезно подумать, почему для JavaScript все-таки есть своя собственная имплементация.
Что в этой ситуации такого показательного?
Противоречие между двумя утверждениями.
В любом высокоуровневом языке основную часть делают «крупными мазками», а то что не получается, делают другими средствами.
Вот только обычно эти "другие средства" все еще часть языка. Нет, не всегда. Но часто. Настолько часто, что я, как разработчик, за пределы используемого языка не выхожу практически никогда.
Значит, вас и разработка внешних компонент не очень волнует. Тогда понятно, почему вы противоречия не видите — вас оно и не затронуло.
PS даже на сях делали ассемблерные вставки и ниче.
Судя по вашему комментарию выше такое есть даже у вас
Какое "такое", и с чем нет противоречий?
Такое встречается даже у вас.
Такое встречается даже у вас.
Встречается, да. Вопрос частоты же.
Возьметесь утверждать, что в случае 1С эта частота такая же или меньше?
Просто вас возмущало что кто то говорил что в 1С делают «крупные мазки», а в случае если не получается делают внешнюю компоненту.
Такое сплошь и рядом.
Такое сплошь и рядом.
В 1С — возможно. В языках программирования общего назначения это, по моим наблюдениям, скорее редкость, чем наоборот.
В том же питоне пишут сначала на питоне, потом делают библиотеку на сях и прикручивают к нему.
Как раз в 1С, это редкость
Так "редкость" или "сплошь и рядом"? Если редкость — то вы, собственно, пытаетесь утверждать, что это реже, чем в других языках, а это как раз то, что вы выше сказали, что не возьметесь делать.
В том же питоне пишут сначала на питоне, потом делают библиотеку на сях
… или нет. Сколько писал на Питоне, никогда так не делал.
Про сплошь и рядом, это я про другие языки. Когда писал на дельфях и сях видел вставки на асме. Когда читаю что делают в питоне, вижу что для увеличения скорости переписывают на си.
Вы не делали, зато другие делали.
В 1С редкость [...] Про сплошь и рядом, это я про другие языки.
Ну то есть вы все-таки утверждаете, что в 1С использование "внешних компонент" происходит реже, чем в языках общего пользования переход на другой язык?
В 1С редкость, последний раз я этим пользовался лет 10 назад
[...]
Вы не делали, зато другие делали.
Люблю, когда человек сам себе отвечает.
Например, есть люди, проработавшие с 1с более 10 лет, и ни разу не сталкивавшиеся с бухучетом.
Вообще, создается впечатление, что вы пытаетесь обсуждать не 1с как таковую, а сложившееся у вас впечатление об 1С. Примерно как опровергатели полетов на луну опровергают не ракету сатурн-5 с двигателями F-1, а какую-то собственнопридуманную ракету ИГП с собственнопридуманными двигателями. которые, естественно, «не взлетят»©
в 1с многие разработчики не то, что «за пределы 1с не выходят» — они не выходят даже за пределы узкой предметной области внутри этой самой 1С.
1С в этом ни капли не уникальна.
Вообще, создается впечатление, что вы пытаетесь обсуждать не 1с как таковую, а сложившееся у вас впечатление об 1С.
Я обсуждаю заявления, которые люди делают об 1С. Мне кажется, я это достаточно четко оговариваю каждый раз.
Серьезно спрашиваю.
Хорошо, тогда буду отвечать серьезно.
Потому что я нахожу очень показательной ситуацию, когда сначала пишут «1С-разработчику остаётся крупными мазками, в терминах бизнес-сущностей „рисовать“ бизнес-процессы», а потом добавляют «у платформы может не существовать штатных методов».
«крупными мазками, в терминах бизнес-сущностей» вполне строится 99% системы. все внешние компоненты — это обычно те вещи, которые для учетных систем (по крайней мере, на момент написания системы) считались второстепенными для реализации. Я уже приводил примеры: связь с ком-портом, сканером, сканером отпечатков, общение с АТС; либо аппаратно зависимы — типа торгового оборудования; Либо существенно расширяют в ущерб политике производителя (прямой доступ к данным); либо существенно улучшают удобство/скорость работы.
А «необычно» от языка зависит.вот и тут — точно так же.
Конфигурирую? На yaml обычно, если выбор есть.наконфигурируете на yaml работу c каким-либо оборудованием/портом/решение СЛАУ?
TensorFlow — это не совсем «существующая в других языках библиотека».
сути это не меняет.
Есть то, что вполне работает, то, что можно применить в проекте (нейронная сеть для классификации, OpenCV для распознавания автомобильных номеров, нечеткое сравнение строк) — почему я не могу применять имеющееся, а должен переписывать на «язык системы» (без разницы, что в данном случае язык системы)?
В контексте этого вопроса полезно подумать, почему для JavaScript все-таки есть своя собственная имплементация.
«крупными мазками, в терминах бизнес-сущностей» вполне строится 99% системы.
99% по объему задач или по времени разработки?
наконфигурируете на yaml работу c каким-либо оборудованием/портом/решение СЛАУ?
Нет.
почему я не могу применять имеющееся, а должен переписывать на «язык системы» (без разницы, что в данном случае язык системы)?
Потому что есть фундаментальная разница между "есть имеющееся, которое я могу применить" и "не могу реализовать, придется делать снаружи".
99% по объему задач или по времени разработки?
И по тому, и по другому.
Внешними компонентами почти всегда решаются очень нетипичные для этой системы задачи: связь 1с с астериском я видел кроме себя только 2 раза (знаю еще о трех). управление «шаттлами» видел только один раз. управление ЧПУ — тоже только 1 раз.
Те тысячи (может, и десятки тысяч) применений ВК для сканирования документов или отправки/полученния почты из 7.7 уже неактуальны потому, что в 8.* уже включены в штатные средства системы — просто потому, что они во второй половине 00-х стали «типичным вариантом поведения».
выше я указал «почти» потому, что некоторые внешние средства расширили штатное поведение, и даже исправили существующие ошибки (потому, что сам разработчик остановил развитие старой версии).
Внешними компонентами почти всегда решаются очень нетипичные для этой системы задачи
Что, собственно, возвращает нас к "пока надо сделать то, на что разработчики платформы рассчитывали". Что, в принципе, нормально...
Более того, не удивлюсь, если половина хабра не знает, что у этой «1с-бухгалтерии» еще какой-то «язык программирования» есть, считают, что это просто «программа для бухгалтерии».
А придурков, пишущих на 1с ассемблер — крайне мало. Но ведь написать — можно?
Так в том и дело, что то, «на что разработчики системы расчитывали» — оно в основном и делается.
А вот это сложный вопрос о курице и яйце. "Оно в основном и делается", потому что кто-то пришел на предприятие, оценил все, что надо сделать, не обнаружил ничего, что не влезает в 1С, и взял 1С (а если что-то не влезает, то взял другую систему), или потому что кто-то пришел на предприятие, взял 1С, и не обнаружил ничего, что не влезает?
Потому что в первом случае это самосбывающееся пророчество: мы не береся за проекты, которые 1С не может, поэтому у нас нет проблем, что 1С не может наши проекты. В этом, заметим, нет ничего особо плохого как в бизнес-подходе.
как правило, никто не может описать все потребности сразу. поэтому «учет влазит в 1С/SAP/MS».
когда основные задачи решены — начинается решение частных задач. тут уже зависит от подхода — кто-то хочет монолит, а кто-то микросервисы. решение частных задач (а оно ни в одной системе не решено) — оно тоже в любом случае требует ресурсов. И тут уже выбор заказчика — делаем или нет. Если делаем — то «внутри 1с», «сбоку от 1с» (те самые внешние компоненты) или «внешними средствами», и 1с просто получает данные. [вместо 1с можно смело подставить Кацапту, насчет ханы — не уверен]. Но «с помощью кувалды, и такой-то матери» можно реализовать практически все, что угодно. вопрос лишь ресурсов.
1с — инструмент, и не более.
1. универсально,
2. удобно,
3. производительно,
4. просто,
5. обнова встала без проблем.
Не всегда это получается, но пытаются.
На любом другом инструменте стоимость похожих продуктов была бы заоблачной.
Вы тоже знаете бейсик и русский язык, но это не говорит о том что вы сможете сесть и выдать программный код сопоставимый с типовыми особенно в предметке где вы не работали.
В Москве как раз джавистов вполне достаточно
[...]
Я тоже JS знаю и писал когда то, но чтобы что то дельное написать на КУБЕ нужно будет поучиться.
Я боюсь, поучиться нужно будет много.
Знать JS и знать фреймворк с предметной областью это разные вещи
так фреймворк с предметной областью — это как раз 1с и есть.
На любом другом инструменте стоимость похожих продуктов была бы заоблачной.
Простите, а сколько, по вашему, стоят "похожие продукты", используемые в странах, где 1С нет?
Не знаю, но не думаю что за 100 баксов можно купить нечто подобное с бессрочным обновлением.
За 100 — нельзя. Но вы-то говорите о "заоблачных" стоимостях. "Заоблачные" — это сколько?
(Любопытства ради, а что конкретно можно купить у 1С за $100 с бессрочным обновлением? Можно ссылку на предложение?)
1С ЗУП (базовая) 8100 руб.
1С УТ (базовая) 6700 руб.
1С Розница (базовая) 3600 руб.
Обновляется через инет, доступ к обновлением бессрочный.
Сколько по вашему мнению может стоить программа по функциональности сравнимая с Бух или УТ.
1С Бух (базовая) 5400 руб. по прайсу
Можно, пожалуйста, ссылку на предложение?
Сколько по вашему мнению может стоить программа по функциональности сравнимая с Бух или УТ.
Я не знаю, что такое "программа, сравнимая по функциональности с". Я знаю, сколько может стоить программа, ведущая учет бухгалтерии — сколько угодно. Бесплатно. Или десятки и сотни долларов на пользователя в месяц. Или несколько тысяч на тенанта в месяц.
Вон, QuickBooks стоит пару десятков баксов в месяц.
Программа сравнимая по функциональности, это значит что и в одной и в другой есть похожий функционал, например MS Office и LibreOffice.
Вот коробку даже за 2600 отдают.
И где там про бесплатное обновление ПО?
Программа сравнимая по функциональности, это значит что и в одной и в другой есть похожий функционал, например MS Office и LibreOffice.
А. Тогда QuickBooks удовлетворяет.
Аренда 1С в облаке самая дешевая которую видел около 750 руб. за пользователя.
QuickBooks это платформа или одна программа по учету?
Базовая поставка обновляется бесплатно
То есть если я купил "1С: Бухгалтерия 8. Базовая версия", то она будет бесплатно обновлена до 9 версии когда та выйдет? А потом до десятой? И так до тех пор. пока компания 1С существует и продолжает выпускать новые версии ПО?
QuickBooks это платформа или одна программа по учету?
Это что-то, что можно купить и вести бухгалтерию в своей компании. Полностью.
Говорю же: есть сильно больше одной страны, где 1С нет или слабо распространен, а бухгалтерия, учет, управление предприятием и все прочие задачи тем не менее успешно решаются.
1С Бух (проф) 13 тыс руб. по прайсу, можно не только бухгалтерию всей компании вести, можно хоть свою бух+ут+crm+ерп+сайт и много чего другого сделать, все зависит от ваших потребностей и умения.
Стран много, программ много, удобных программ мало.
Думаю как миниму до конца 8ой версии будет, а вообще это от 1С зависит
Это немножко отличается от "бессрочного обновления". Обновления в рамках одной мажорной версии — это более-менее норма, не очень понимаю, зачем из даже упоминать.
много чего другого сделать, все зависит от ваших потребностей и умения
"Сделать" тоже не бесплатно ведь.
А то понимаете ли, на <тут вписать язык общего назначения> можно сделать все описанное и немного больше, зависит от потребностей и умения. И внезапно будет бесплатно, если правильный язык выберете.
Стран много, программ много, удобных программ мало.
Ну то есть от "на любом другом инструменте стоимость похожих продуктов была бы заоблачной" переходим к "другие продукты хуже", да?
Это немножко отличается от «бессрочного обновления». Обновления в рамках одной мажорной версии — это более-менее норма, не очень понимаю, зачем из даже упоминать.
8ке я уже не помню сколько лет, и девяткой даже и не пахнет.
«Сделать» тоже не бесплатно ведь.
Если сами будете делать, то бесплатно. А также конфигурации 1С довольно не плохо синхронизируются между собой.
Ну то есть от «на любом другом инструменте стоимость похожих продуктов была бы заоблачной» переходим к «другие продукты хуже», да?
Нет, не хуже. Каждый инструмент приспособлен для своей задачи. Но и 1С не хуже других и как инструмент в нужных для нее местах приспособлен лучше.
Если сами будете делать, то бесплатно.
Э… нет. Рабочее время — не бесплатно.
Нет, не хуже.
Ну то есть и стоимость похожих продуктов не заоблачна, и продукты не хуже.
Что, собственно, и требовалось доказать.
Мне, в принципе, достаточно того, что утверждение "на любом другом инструменте стоимость похожих продуктов была бы заоблачной" оказалось необоснованным.
Стоимость владения на рынке РФ
В треде явно сказано: "сколько, по вашему, стоят "похожие продукты", используемые в странах, где 1С нет?" РФ под это определение явно не попадает, так какое нам дело до стоимости владения на этом рынке?
(это еще не вдаваясь в том, что "стоимость продуктов на инструменте" для меня — это стоимость разработки в первую очередь)
Это не про РФ уже?
Какие цены дали, на такие и смотрим. Дали в РФ — смотрим на РФ. Мой вопрос все равно про за пределами РФ.
Хотя вы к этому подводит.
Разве?
Раз уж вы заикнулись, что все можно написать на том же языке
Вы точно меня ни с кем не путаете?
расскажите, что же это за такой замечательный ЯП общего назначения, который может решать бизнес задачи так же как и 1С.
Язык не решает бизнес-задачи. ПО решает бизнес-задачи. ПО, да, пишется на каком-то языке (возможно, с использованием какого-то фреймворка или платформы).
Так вот, я точно знаю, что на .net можно написать продукт, который решает те же бизнес-задачи (не обязательно все, но много), что и 1С. Ну и не .net единым, просто берем список ERP, использующихся в США, и ищем, на чем они написаны. Вот вам и будет список "замечательных языков общего назначения".
Из этих слов я сделал вывод c++.
… неправильный.
Это чуть ли единственный язык на чем написаны остальные языки
… а на чем написан C++?
Впрочем, вы прекрасно понимаете, что это неправильная логика.
От сюда следует 1С к ним тоже относится.
И что?
Вы сами свои комментарии быстрей меня просмотрите.
За одно и то же время (ну то есть, в зависимости от скорости чтения, но вы про мою ничего не знаете в любом случае).
Но нет, я не помню, чтобы я что-то подобное писал.
Это ваши слова.
Это мои слова, которые что? Из них не вытекает, как вы мне приписываете, что "все можно написать на том же языке".
когда их собираешь в кучу, это чистейшей воды манипуляции
Я не знаю, что вы считаете манипуляцией, но вот то, что вы читаете в моих комментариях то, что там не написано — это хорошо видно.
Дальнейшие дискуссии считаю бессмысленными.
Это очень удобная позиция — сначала прийти в дискуссию с вопросом, а потом, получив неудобный ответ, уйти со словами "дальнейшие дискуссии считаю бессмысленными".
Ну да, я тоже считаю достаточно бессмысленными попытки оспорить ложность утверждения "на любом другом инструменте стоимость похожих продуктов была бы заоблачной", но вы же их начали зачем-то?
Иногда надо читать между строк.
Ну да, там-то можно прочитать что угодно.
Простите, а где я получил хоть один ответ?
В комментариях выше.
Вы ни разу не сослались на свой опыт.
Да ладно. Вот прямо в процитированном вами: "я, как разработчик, за пределы используемого языка не выхожу практически никогда", "это, по моим наблюдениям, скорее редкость, чем наоборот". Прямая отсылка к моему опыту.
А рассуждаете об инструментах с которыми скорее всего не работали.
Это где, например? Я очень аккуратно стараюсь рассуждать о чужих заявлениях.
По поводу на "любых других инструментах" я прекрасно себе отдаю отчёт, что вне РФ 1С пока что ничего предоставить не может.
Ну то есть заявление, к которому я отсылаюсь, все-таки необосновано?
А вы пока ни одного вменяемого довода не привели, почему нет.
А я, собственно, и не утверждал, что нет. Я (а) спрашивал, сколько стоят похожие продукты (можете считать это намеком, что заявление о стоимости этих продуктов, сделанное оппонентом, ложно), и (б) спрашивал, почему да.
Вы ни разу не обмолвились на каких языках пишете.
А зачем? У меня нет задачи доказать, что язык, на котором я пишу, круче всех. Мне интересны утверждения, которые делаются в ходе дискуссии, а они никак не связаны с языком, на котором я пишу.
И второе, вы часто ровняете ЯП и фрэймворк. 1С это даже не фрэймворк это готовая ерп платформа.
А я ровняю? Или это вы между строк снова читаете?
Впрочем, в данном треде речь идет об инструментах, и о финальной стоимости разработки на этих инструментах. В этом контексте не важно, будет инструмент фреймворком или языком.
что же это за такой замечательный ЯП общего назначения, который может решать бизнес задачи так же как и 1С.
COBOL жеж!
В 99% случаев это не 1с глючит, а у кого-то руки кривые из пользователей
. Так как 1С: Битрикс — 100% совместим.
Битрикс имеет отношение к 1С только своим названием. А учитывая что конфигураций у 1С существует великое множество — битрикс не может быть «совместим» с ними всеми
<Давно мечтаю о CMS, которая при выводе каталога, лезет за остатками непосредственно в БД 1С.>
Это сложно сделать с лицензионной точки зрения, а уж потом с технической
нО есть куча обходных путей и вариантов, но да, проще всего сказать что 1С кривой и ничего не делать
===
а в 99% случаев проблемы такие:
1) срочно надо сделать отгрузку товара который не успели оприходовать «ололо, грузовик стоит, очередь ждет, omg бегом бегом!!»
2) отключается контроль остатков — печатается накладная
3) оказывается товар оприходовали с другим названием (оно реально изменилось)
4) имеем -100 остатка по старому и +100 по новому, по факту на складе ни того ни другого
5)…
6) ВИНОВАТ КРИВУЩИЙ ГЛЮЧНЫЙ 1С!!!
Мы ещё лет 5 назад пытались использовать 1С через HTTP API как бэкенд через прокси для SPA типа магазина публичного. Функционально всё работало, лицензия вроде не нарушалась, но вот работало очень медленно. Отчасти связываю с тем, что для специалистов по 1С, с которыми мы сотрудничали, всё это было в диковинку: и веб, и постгри в качестве СУБД.
XML, насколько я помню. Я сам непосредственно с 1С не работал, но в целом команда разбиралась в веб-разработке и ситуацию 1+N запросов повсеместно вряд ли бы допустила. Из тех проблем, что в памяти остались: какие-то сложности с пагинацией, сложности с отдачей "превью" объектов для списков — или полностью со всей вложенностью, или какие-то костыли, требующие кучу времени на малейшие изменения.
Давно мечтаю о CMS, которая при выводе каталога, лезет за остатками непосредственно в БД 1С.И убивает нахрен сервер БД 1С.
Запустили даже, но проект не взлетел — это был 2004 год. немного «опередили время»…
Конфигурация похожа на 1с унф, но немного отстает в принципе, потенциал у платформы есть, но нужна действительно доступное количество партнеров, веду переговоры с парой другой бизнесов, мультифирменность и урбд из коробки, это очень приятная киллер фича. В целом весь основноная проблема, что 1с совершенно не вливает бабки в развитие рынка, т.е. не предоставляет маркетинговые материалы, не предоставляет площадки для выставки.
В итоге я столкнулся с такой ситуацией, чтобы что то продать, надо что-то внедрить, чтобы что то внедрить, нужно сделать это практически бесплатно. Т.е. предоставить для каждой страны минимальный набор success сторис.
Ну в общем я сейчас на этом этапе. Генерирую success сторис для той страны в которой нахожусь.
Но по большому счету, это как развивать веб студию с нуля, сначала делаешь проекты почти за даром, а затем работает сарафан. Топик стартер по сути просто болтает.
The App Maker editor and user apps will be shut down on January 19, 2021. New application creation will be disabled starting April 15, 2020.
1C победил
1) Основное преимущество 1с: это поддержка вечно меняющегося регламентированного учета в РФ. Оно сходит на ноль в других странах, т.к. в них нет столько изменений в регл учете. И тогда 1с придется конкурировать даже с чем-нибудь древним, 20 лет назад написанным. Проще говоря: конкуренция выйдет на порядки больше (даже не в разы).
2) В некоторых странах у малого бизнеса допускается вообще отсутствие регл учета. И поэтому 1с тут сможет конкурировать только в сфере управленческого учета, а значит придется конкурировать и с CRM.
3) У 1с тяжеловато с разделением продуктов по сложности. Больше 1с делит их по отраслям. А вот так, чтобы у «Управление торговлей» появилось 3 компоновки по функционалу/сложности/стоимости — такого нет. И механизмов скрытия от пользователя (функциональные опции) недостаточно, т.к. сложность всей конфигурации остается на высоком уровне (а значит теряет в производительности и выше стоимость доработки).
4) Зато у конкурентов много не-технических преимуществ: например, у них есть уже доля рынка и репутация. У некоторых (SAP) репутация такая, что внедрившие ее компании автоматически повышают свою капитализацию.
5) Про SAP отдельный разговор. У них с 1с концептуально противоположный подход к автоматизации.
Подход SAP: процессы должны быть такими, учет всегда таким. Перестраивайте фирму под них. Зато любой может посмотреть «отчет по продажам» и однообразно увидеть состояние фирмы.
Подход 1с: вот вам конструктор, там заложены пара базовых принципов, а дальше меняйте как хотите. Процессы и учет меняют под фирму. Поэтому тот же «отчет по продажам» может как угодно различаться и показывать разное в зависимости от фирмы и ее желаний.
Отсюда внедрение SAP повышает капитализацию (т.к. в фирму внедрили пусть не идеально работающие, но работающие процессы), а внедрение 1с никак не влияет на капитализацию (т.к. процессы могли остаться на любом пещерном уровне).
почему переход будет на порядок хуже? :)
потому, что «на java, .net» придется заново реализовывать еще и то, что реализовано в типовых механизмах. Не, ошибки, конечно, отловят… Но это еще то удовольствие — кувыркаться с глючащей бизнес-логикой на глючащих механизмах. На 1с это тоже было (да и сейчас есть, не столь массово только)
Как коронавирус (COVID-XX) может помочь 1С захватить мир?