TheBrain — крутая штука. Когда работал в одной фирме в начале нулевых, у нас была какая-то версия этой программы (не похоже на текущие скриншоты, соединительные линии были прямыми). Ее использовали как CRM-систему: Регионы -> Города -> Организации с аффилированными лицами -> Сотрудники -> Контакты. Выглядело очень солидно и найти информацию можно было несколькими кликами мышки. Я сделал им дополнительный раздел и внес базу знаний из нашей предметной области — тоже вышло очень круто. Спасибо, что напомнили! Схожу проверю какие еще функции они за десять лет успели добавить…
Переписывать все нужно с нуля, причем с открытым исходным кодом и без всякого русского языка в синтаксисе, а на общедоступных скриптовых языках. Это я говорю как программист 1С с 5 летним стажем знающим ассемблер, С++, C#, JavaScript.
Судя по качеству комментариев, то тут все со значительным 1С-стажем и знанием линейки «ассемблер, С++, C#, JavaScript», но только вы хотите избавится от платформы и перейти на что-то другое. Так в чем же дело, что вас останавливает? Ваш выбор Odoo (бывшая OpenERP), которая и опенсурс, и на популярном питончике, и на котором уже много бухгалтерских и прочих конфигураций создано — все как вы и хотели. Их типовые решения даже на русский язык локализированы, но никто не мешает вам писать «с нуля» и продавать свою поделку.
Вот только тут полная аналогия айфонов и андроидофонов. С одной стороны закрытая аппаратная платформа и ОС, которые контролируются вендором; а с другой стороны зоопарк тысяч кастомизаций различных версий операционки под сотни различных девайсов — тонны аппаратных и программных глюков, в которых даже никто не пытается разбираться. Причины популярности среди покупателей «закрытых» решений очевидны.
Конфигуратор — это комплексный продукт, который предназначен не только для разработки, но и для отладки (это в 7.7 были разные программы). Я тоже не вижу особых проблем с настройкой технологического журнала напрямую из конфигуратора с последующим анализом накопленной информации. Обеими руками за такую фичу!
Похоже, что автор статьи не очень в теме опенсорса (раз такие несправедливые закидоны в сторону мелкомягких). Да и вообще складывается впечатление, что написал он ее в расстроенных чувствах, что его проект на гитхабе никто не хочет контрибутить.
Например, вы пишите, что понимаете, для чего блокчейн врачам и юристам. Хотелось бы услышать ваше мнение — для чего же?
С одной стороны для контроля — врач не может дать заднюю и подделать бумаги, если его действия причинили вред пациенту. С другой стороны если будет существовать единая блокчейн-система между больницами, то это «карточка пациента», которая ходит за пациентом — каждый новый врач будет видеть историю болезни и ее лечения; да и сам пациент будет точно знать за что платит деньги. (Пример придумал на ходу, эксперты могут что-то круче придумать)
Персональные данные сотрудников и клиентов? Каким образом мы разглашаем эти сведения?
Т.е. вы планируете обезличенно писать в публичный блокчейн: смену открыл Повар№357, поступила жалоба Клиента№7425 на Официанта№248, была выплачена зарплата Водителю№6?
Конкурентам интересно как мы купили молоко? Или по какой цене? Как нам его доставили и кто его разгрузил?
Все зависит от конкурентов. В торговой фирме, где я работал в 2003 директор очень переживал, чтобы данные базы не попали в чужие руки и СБ внимательно следила, что бы даже мы никуда бекапы не выносили. Если у вас нет никаких особых договоров и вы закупаете свои молоко, масло, муку и сахар просто у первых попавшихся, кто предлагает дешевую цену, то наверное переживать не за что.
Вы не узнали из статьи о том, для чего блокчейн ресторанному бизнесу. Статья вводная. И очень объемная. В последующих статьях я обязательно отвечу на это вопрос.
Как бы статья называется «блокчейн в бизнес-модели кондитерской», а вовсе не «Как мы готовимся к ICO» или «Разработка системы управления рестораном». Много картинок, много истории вашего бизнеса, но мало самой «идеи».
Я имею понимание чем полезен блокчейн для нотариусов, юристов, банкиров, врачей и так далее. Надеялся из статьи узнать чем может быть полезен блокчейн в ресторанном производственно-торговом бизнесе. Но не узнал :(
Существуют сотни (или может быть тысячи) программ для ресторанов и кафе, в которых можно вести весь описанный выше учет, и которые дают дашборды с актуальными данными для руководства. Зачем изобретать SIMT, если ваш опыт в автоматизации HoReCa стремится у нулю?
Еще больше не понимаю зачем фиксировать в блокчейне и потом всем инвесторам показывать какую-то ерунду. К примеру, те же опоздания повара. Мне пофигу его трудовая дисциплина, если бы я был инвестором такого проекта, то меня в первую очередь интересовало, чтобы когда клиент приходит в кондитерку, то он мог купить свежее и вкусное пирожное — т.е. главное что бы повар справлялся с возложенной на него работой и мог за это получить премию. Но какой-то другой инвестор с одним единственным токеном скажет, что за дисциплину нужно бороться и повара премии необходимо лишить вовсе. Третий поддержит второго, но дополнительно потребует наложить штраф. Четвертый назовет повара неисправимым мудаком и потребует его увольнения. Что это все за бред??? К тому же не уверен, что вы имеете законное право на разглашение персональных данных сотрудников и клиентов. А конкурентам наоборот будет интересно приобрести за какой-то жалкий токен доступ ко всем вашим взаимоотношениям с поставщиками.
И вообще не увиделв статье зачем вам блокчейн. Вы хотите бороться со своим нечестным персоналом? Зачем вы приняли на работу вора, зная что он вор? А если произошла ошибка? Ошибка уже в блокчейне и нужно срочно останавливать все процессы и удалив «сбойное» звено перегенерировать всю цепочку после него. Или вы для корректировок внесете специальные корректировочные документы? Браво! Вы только что придумали идеальный способ обмануть систему для ваших сотрудников-негодяев. Да и вообще не вижу для вас никаких преимуществ перед обычными базами данных, в которых отлично решаются вопросы доступа и логирования всех телодвижений операторов.
И финальная «кулявлоб». После прочтения статьи у меня сложилось впечатление, что вы изобретаете свою собственную систему «акционерного общества». Токены — это ваши акции, которые (по вашим словам) дают право на участие в дележе прибыли. Но только в отличии от акций акционеров, существование которых регулируется на уровне государственных законов, ваши «акции» регулируются только вашей доброй волей. Собрали на ICO деньги, помахали ручками «инвесторам» и отправились отдыхать на острова; а обманутые вкладчики даже в суд подать не могут, так как их цифровые фишки — это просто какие-то ничем не обеспеченные и не гарантированные цифровые фишки.
Поэтому я и решил посоветоваться с хар-сообществом, но вместо позитива меня заминусовали.
Я хоть и не плюсовал, но и не минусовал. Как-то нейтрален к вашей истории. Но вам не нужно сейчас включать обиженного и жаловаться на непонимание сообществом. Если хотели посоветоваться, то нужно было открыто просить совета в статье, а не пиарить RAD Studio и не пытаться искать потенциальных заказчиков на оказавшуюся ненужной программу.
Нельзя просто взять сказать «я сделал ERP-систему» и далее рассказывать о том, как парсишь PDF-документ и с телефона передаешь GPS-трек. Нельзя, потому что самое быстрое внедрение уже готовой ERP-системы про которое я слышал заняло три месяца (настройки, обучение, перенос данных). Внедрения с доработками идут по году. А написание систем для управления ресурсами предприятия «с нуля» занимает годы.
Что еще не так в статье? Не сказано, чем именно не устраивала система FARFOR, какие блоки автоматизации процессов были доработаны и какие вообще написаны заново, как именно была выполнена связка с основной системой? Я так и не понял — у вас «прокси» на корпоративный софт с вашим дополнительным функционалом или отдельная самостоятельная полноценная система, которая никак не зависит от легаси и имеет с ней двухстороннюю синхронизацию как отключаемую опцию? В целом, ну никак не показана ценность созданной системы. У меня сложилось впечатление, что вы просто какой-то плагин сделали, который работает исключительно поверх чужой программы.
Нет там никакого кунг-фу. Был по обе стороны барикад (и как android-разработчик и как 1С-разработчик) еще до изобретения в платформе «1С: Предприятие 8» такой простой и приятной штуки как HTTP-сервисы, но и тогда не было особых причин для жалоб. Сейчас несложно организовать обмен с 1С по обычным HTTP-запросам (get, post, put, delete и всеми прочими), даже формат данных можно задавать самостоятельно — XML, JSON или что-то свое (но парсинг на стороне 1С придется делать самостоятельно).
упремся в какие-нибудь сторонние решения типа Агент Плюс (со своим же скриптовым языком, и отдельными лицензиями на каждое клиентское устройство)
Что вы хотели этим сказать? Что «работу» нужно «работать»? Так нам же за это деньги платят! :)
В Агент Плюсе 1.5 применяется простой и всем известный Lua, а в двоечке действительно решили все сделать максимально как в 1С и выпустили конфигуратор, где можно точно так же как в 1С создавать новые объекты, описывать их интерфейс и писать код на 1С-подобном языке L9 (детальнее).
VolCh, не люблю цитировать википедию, но уж больно хорошо у них написано:
Enterprise Resource Planning, планирование ресурсов предприятия
ERP (англ. Enterprise Resource Planning, планирование ресурсов предприятия) — организационная стратегия интеграции производства и операций, управления трудовыми ресурсами, финансового менеджмента и управления активами, ориентированная на непрерывную балансировку и оптимизацию ресурсов предприятия посредством специализированного интегрированного пакета прикладного программного обеспечения, обеспечивающего общую модель данных и процессов для всех сфер деятельности. ERP-система — конкретный программный пакет, реализующий стратегию ERP. (с) Википедия
Термин ERP придумал Ли Уайли в 1990 году
Понятие ERP ввёл аналитик Gartner Ли Уайли (англ. Lee Wylie) в 1990 году в исследовании о развитии MRP II. Уайли спрогнозировал появление тиражируемых многопользовательских систем, обеспечивающих сбалансированное управление всеми ресурсами организации, не только относящихся к основной деятельности производственного предприятия, но и объединяющих посредством общей модели данных данные о производстве, закупках, сбыте, финансах, кадрах. (с) Википедия
Вы начали писать все верно, по потом пошла какая-то вода: «как правило, но есть много исключений», «может импортировать, а может и не делать этого», «имеется тенденция»… Прямо как Гидромецентр со своими прогнозами: может дождь, может снег, может будет, может нет :)
По факту: главной идеей и целью концепции и программ ERP является рачительное управление производственными ресурсами. Именно из-за несоответствия описанного функционала к примененному термину ERP, я прицепился к автору. Про планировании закупок не было ни слова, как я уже упомянул выше. Так же ни слова не сказано даже о самом базовом — планировании самого производства. Где-то в комментариях автор упомянул, что там в его системе есть рецепты, но он про такой «очевидный» функционал просто не стал писать. Этого мало! Те же рецепты можно на листиках от руки написать и на стенках повесить. А должен быть как минимум анализ потребностей кухни на основе уже собранных заказов (плюс прогнозируемые заказы на базе собранной в прошедшие периоды статистики), что бы завхоз еще утром был в курсе, что в обед на кухне тех же листьев нори уже не будет.
Возможно у вас именно ERP и вы полностью повторили функциональность SAP R3, но почему вы в статье рассказывали исключительно только про CRM (работа с клиентами), HRM (работа с персоналом) и TMS (работа с доставкой)? Вам же подсказывают про MRP I и MRP II. Где ваши анализы сезонных продаж (с учетом праздников) и составление на их основе планов производства и закупки ингредиентов (закупите больше — увеличите затраты из-за просрочки неиспользованного; закупите меньше — получите недополученную прибыль и уменьшение лояльности покупателей)? Где ваши расчеты по заготовке полуфабрикатов (последний элемент для суши и пиццы вообще очень важен, так как эти классы продуктов компонуют из заготовок, срок жизни которых от пары часов до суток, а потом нужно буквально утилизировать «деньги»)?
Когда конфигурация требует обновления терпимой версии платформы на заведомо бажную — это лютый фейл, согласен.
Вспомнил историю примерно 2012-2013 года. В Украине в очередной раз решили, что какие-то из отчетов снова нужно сдавать по-другому. Обновление реготчетности компания ABBYY выдала вместе с новым релизом Бухгалтерии, который для своей установки требовал новый на днях выпущенный релиз платформы. И так совпало, что именно в этой новой версии платформы был лютый баг, который удалял значение субконто у проводок. Вот это был фейл!
Первый блин комом, не смотря на 7-летний стаж. Надеюсь, что свою следующую статью вы дадите написать Юрию Жданову — у него превосходно получается работать с аудиторией. Даже, если не будет чего-то супер-эксклюзивного, то и повторение технологии «квадры» тоже людям зайдет. Удачи.
Просто статья мне напомнила про моего друга, который тоже давно хочет «соскочить с 1С». Сначала купил книгу по С++ и полностью всю ее прочитал. Даже сделал парочку ВК для 1С, что бы материал закрепить. Потом забросил… Далее решил заняться Джавой и прошел курс ДжаваРаш, написал парочку мобильных приложений… и тоже забросил. Далее нашел какую-то систему по аналогии с 1С, но где программируют на JavaScript — поставил, крутил, пробовал что-то дорабатывать… В общем прошло уже несколько лет, а он как работал программистом 1С, так ничего в его жизни существенно не изменилось. И да, ему тоже платят хорошую зарплату и его основная мотивация была только в том, что бы «сесть на трактор».
Еще один комментарий, но уже без цитат.
1) Вы предлагаете снимать программу с поддержки и писать данные по конфигурации напрямую в конфигурацию. Для Бухгалтерий, которые регулярно самостоятельно обновляются без участия «программиста» — это не выход из-за поломки такого автообновления и вам выше правильно напомнили про возможность создать сервис с помощью расширения, который будет выдавать нужную информацию.
2) И еще вы совершенно верно указали, что названия таблиц при реструктуризации изменяются. Так от куда у вас взялась идея, что ваша таблица с метаданными ВСЕГДА будет называться _InfoReg27083? Ее название тоже может легко изменится при обновлении, когда изменится состав дерева метаданных (или при переходе на новую версию платформы). Т.е. вместо того, что бы просто брать готовые данные, вы сами себя обрекаете на перепроверку и возможное переписывание ваших скриптов для каждой из попыток загрузки.
*) И сколько можно про русский язык? Если вы не знаете русского языка, то пишите код на английском. Есть целые линейки программ из серии «1С: Предприятие», которые ориентированы на внешний рынок и написаны полностью на английском языке без единого русского слова (есть даже две типовые конфигурации, которые пишет сама компания 1С, а не ее партнеры — Small Business и Accounting Suite). Вот только на русскоязычной территории СНГ и ближнего зарубежья (Прибалтика, Молдова и пр.) предпочитают именно русский язык и это является конкурентным преимуществом при распространении.
Согласен с коллегами, которые отписались выше. У вас изначально были неправильные предпосылка и потому вы пошли не тем путем.
Для захвата данных из 1С у вас есть 2 пути:
То, что вы описали как четыре минуса для получения данных с помощью стандартных средств 1С (SOAP, OData или HTTP-сервисы с XML/JSON), вообще к ним не относятся.
Появляется еще один источник для ошибок в виде дополнительных выгрузок-загрузок,
расписаний, роботизации
Расписания выгрузок/загрузок и прочая «роботизация» находится на вашей стороне, а 1С при таком подходе выступает как сервер данных: вы сделали запроса и получили ответ. Формально это даже не минус, а просто реалии вашей работы как «ETL-специалиста» с любым источником данных.
Это будет работать существенно медленнее из-за особенностей интерфейсов 1С
Что же это за особенности? У меня уже есть ряд мобильных разработок для удаленной работы с базами 1С и они работают довольно шустро даже в сценариях, когда требуется полная и актуальная НСИ. В первом варианте происходит быстрая выборка, сериализация в нужный формат и возврат веб-сервером. Во втором варианте перед запросом нужно каждый раз актуализировать информацию по меппингу и только затем уже можно выбирать данные и преобразовывать в тот вид, с которым вы будете далее работать.
При любых изменениях в захватываемых данных, вам придется вносить изменения в выгрузки
В первом подходе никаких изменений вносить не требуется, а при непосредственном доступе к СУБД из-за изменения структуры и названия таблиц эти изменения постоянны.
Это вызовет больше ошибок в целостности данных, чем работа напрямую с СУБД
Тут даже комментировать особо нечего. Весь контроль целостности находится на стороне платформы, которая гарантирует в 99,9% случаев успешные чтение и запись (еще есть редкие случаи сбоев самой СУБД на которые 1С влиять не может). А вот бездумный INSERT/UPDATE/DELETE напрямую в СУБД может натворить делов… Но вы же в статье только про получение информации говорите? Тогда какая к черту целостность? Скорее тут вопрос в согласованности данных! В режиме 1С вы получаете гарантированно цельный и согласованный объект, а в режиме СУБД можете напутать с версиями и JOIN-ми табличных частей. Не говоря уже о том, что легко нарваться на грязное чтение.
Получил две статьи по цене одной :)
А вы не хотели бы осветить работу со стандартами более широко, возможно в виде статьи? Тема интересная, особенно в свете ваших слов «Потому, что с 2008 года во всем мире ВСЕ процессы (в том числе и абсолютно все бизнес-процессы) построены по готовым стандартам.»
Изучайте системный подход, стандарты типовых ПРОЦЕССОВ из ISO IEC IEEE ANSI EN BS, выкиньте кривые ГОСТы (они устарели лет на 15 минимум)
И тем не менее гугление по вашему стандарту IEC 61512 выдает именно ГОСТ Р МЭК 61512-1-2016, который создан на базе IEC 61512-1:1997
Судя по качеству комментариев, то тут все со значительным 1С-стажем и знанием линейки «ассемблер, С++, C#, JavaScript», но только вы хотите избавится от платформы и перейти на что-то другое. Так в чем же дело, что вас останавливает? Ваш выбор Odoo (бывшая OpenERP), которая и опенсурс, и на популярном питончике, и на котором уже много бухгалтерских и прочих конфигураций создано — все как вы и хотели. Их типовые решения даже на русский язык локализированы, но никто не мешает вам писать «с нуля» и продавать свою поделку.
Вот только тут полная аналогия айфонов и андроидофонов. С одной стороны закрытая аппаратная платформа и ОС, которые контролируются вендором; а с другой стороны зоопарк тысяч кастомизаций различных версий операционки под сотни различных девайсов — тонны аппаратных и программных глюков, в которых даже никто не пытается разбираться. Причины популярности среди покупателей «закрытых» решений очевидны.
С одной стороны для контроля — врач не может дать заднюю и подделать бумаги, если его действия причинили вред пациенту. С другой стороны если будет существовать единая блокчейн-система между больницами, то это «карточка пациента», которая ходит за пациентом — каждый новый врач будет видеть историю болезни и ее лечения; да и сам пациент будет точно знать за что платит деньги. (Пример придумал на ходу, эксперты могут что-то круче придумать)
Т.е. вы планируете обезличенно писать в публичный блокчейн: смену открыл Повар№357, поступила жалоба Клиента№7425 на Официанта№248, была выплачена зарплата Водителю№6?
Все зависит от конкурентов. В торговой фирме, где я работал в 2003 директор очень переживал, чтобы данные базы не попали в чужие руки и СБ внимательно следила, что бы даже мы никуда бекапы не выносили. Если у вас нет никаких особых договоров и вы закупаете свои молоко, масло, муку и сахар просто у первых попавшихся, кто предлагает дешевую цену, то наверное переживать не за что.
Как бы статья называется «блокчейн в бизнес-модели кондитерской», а вовсе не «Как мы готовимся к ICO» или «Разработка системы управления рестораном». Много картинок, много истории вашего бизнеса, но мало самой «идеи».
Буду с интересом ждать вашу следующую статью.
Существуют сотни (или может быть тысячи) программ для ресторанов и кафе, в которых можно вести весь описанный выше учет, и которые дают дашборды с актуальными данными для руководства. Зачем изобретать SIMT, если ваш опыт в автоматизации HoReCa стремится у нулю?
Еще больше не понимаю зачем фиксировать в блокчейне и потом всем инвесторам показывать какую-то ерунду. К примеру, те же опоздания повара. Мне пофигу его трудовая дисциплина, если бы я был инвестором такого проекта, то меня в первую очередь интересовало, чтобы когда клиент приходит в кондитерку, то он мог купить свежее и вкусное пирожное — т.е. главное что бы повар справлялся с возложенной на него работой и мог за это получить премию. Но какой-то другой инвестор с одним единственным токеном скажет, что за дисциплину нужно бороться и повара премии необходимо лишить вовсе. Третий поддержит второго, но дополнительно потребует наложить штраф. Четвертый назовет повара неисправимым мудаком и потребует его увольнения. Что это все за бред??? К тому же не уверен, что вы имеете законное право на разглашение персональных данных сотрудников и клиентов. А конкурентам наоборот будет интересно приобрести за какой-то жалкий токен доступ ко всем вашим взаимоотношениям с поставщиками.
И вообще не увиделв статье зачем вам блокчейн. Вы хотите бороться со своим нечестным персоналом? Зачем вы приняли на работу вора, зная что он вор? А если произошла ошибка? Ошибка уже в блокчейне и нужно срочно останавливать все процессы и удалив «сбойное» звено перегенерировать всю цепочку после него. Или вы для корректировок внесете специальные корректировочные документы? Браво! Вы только что придумали идеальный способ обмануть систему для ваших сотрудников-негодяев. Да и вообще не вижу для вас никаких преимуществ перед обычными базами данных, в которых отлично решаются вопросы доступа и логирования всех телодвижений операторов.
И финальная «кулявлоб». После прочтения статьи у меня сложилось впечатление, что вы изобретаете свою собственную систему «акционерного общества». Токены — это ваши акции, которые (по вашим словам) дают право на участие в дележе прибыли. Но только в отличии от акций акционеров, существование которых регулируется на уровне государственных законов, ваши «акции» регулируются только вашей доброй волей. Собрали на ICO деньги, помахали ручками «инвесторам» и отправились отдыхать на острова; а обманутые вкладчики даже в суд подать не могут, так как их цифровые фишки — это просто какие-то ничем не обеспеченные и не гарантированные цифровые фишки.
Я хоть и не плюсовал, но и не минусовал. Как-то нейтрален к вашей истории. Но вам не нужно сейчас включать обиженного и жаловаться на непонимание сообществом. Если хотели посоветоваться, то нужно было открыто просить совета в статье, а не пиарить RAD Studio и не пытаться искать потенциальных заказчиков на оказавшуюся ненужной программу.
Что еще не так в статье? Не сказано, чем именно не устраивала система FARFOR, какие блоки автоматизации процессов были доработаны и какие вообще написаны заново, как именно была выполнена связка с основной системой? Я так и не понял — у вас «прокси» на корпоративный софт с вашим дополнительным функционалом или отдельная самостоятельная полноценная система, которая никак не зависит от легаси и имеет с ней двухстороннюю синхронизацию как отключаемую опцию? В целом, ну никак не показана ценность созданной системы. У меня сложилось впечатление, что вы просто какой-то плагин сделали, который работает исключительно поверх чужой программы.
Нет там никакого кунг-фу. Был по обе стороны барикад (и как android-разработчик и как 1С-разработчик) еще до изобретения в платформе «1С: Предприятие 8» такой простой и приятной штуки как HTTP-сервисы, но и тогда не было особых причин для жалоб. Сейчас несложно организовать обмен с 1С по обычным HTTP-запросам (get, post, put, delete и всеми прочими), даже формат данных можно задавать самостоятельно — XML, JSON или что-то свое (но парсинг на стороне 1С придется делать самостоятельно).
Что вы хотели этим сказать? Что «работу» нужно «работать»? Так нам же за это деньги платят! :)
В Агент Плюсе 1.5 применяется простой и всем известный Lua, а в двоечке действительно решили все сделать максимально как в 1С и выпустили конфигуратор, где можно точно так же как в 1С создавать новые объекты, описывать их интерфейс и писать код на 1С-подобном языке L9 (детальнее).
Вы начали писать все верно, по потом пошла какая-то вода: «как правило, но есть много исключений», «может импортировать, а может и не делать этого», «имеется тенденция»… Прямо как Гидромецентр со своими прогнозами: может дождь, может снег, может будет, может нет :)
По факту: главной идеей и целью концепции и программ ERP является рачительное управление производственными ресурсами. Именно из-за несоответствия описанного функционала к примененному термину ERP, я прицепился к автору. Про планировании закупок не было ни слова, как я уже упомянул выше. Так же ни слова не сказано даже о самом базовом — планировании самого производства. Где-то в комментариях автор упомянул, что там в его системе есть рецепты, но он про такой «очевидный» функционал просто не стал писать. Этого мало! Те же рецепты можно на листиках от руки написать и на стенках повесить. А должен быть как минимум анализ потребностей кухни на основе уже собранных заказов (плюс прогнозируемые заказы на базе собранной в прошедшие периоды статистики), что бы завхоз еще утром был в курсе, что в обед на кухне тех же листьев нори уже не будет.
Возможно у вас именно ERP и вы полностью повторили функциональность SAP R3, но почему вы в статье рассказывали исключительно только про CRM (работа с клиентами), HRM (работа с персоналом) и TMS (работа с доставкой)? Вам же подсказывают про MRP I и MRP II. Где ваши анализы сезонных продаж (с учетом праздников) и составление на их основе планов производства и закупки ингредиентов (закупите больше — увеличите затраты из-за просрочки неиспользованного; закупите меньше — получите недополученную прибыль и уменьшение лояльности покупателей)? Где ваши расчеты по заготовке полуфабрикатов (последний элемент для суши и пиццы вообще очень важен, так как эти классы продуктов компонуют из заготовок, срок жизни которых от пары часов до суток, а потом нужно буквально утилизировать «деньги»)?
infostart.ru/public/703188
И тогда же в вашем личном блоге:
business-programming.blogspot.ru/2017/11/blog-post_23.html
Вспомнил историю примерно 2012-2013 года. В Украине в очередной раз решили, что какие-то из отчетов снова нужно сдавать по-другому. Обновление реготчетности компания ABBYY выдала вместе с новым релизом Бухгалтерии, который для своей установки требовал новый на днях выпущенный релиз платформы. И так совпало, что именно в этой новой версии платформы был лютый баг, который удалял значение субконто у проводок. Вот это был фейл!
Просто статья мне напомнила про моего друга, который тоже давно хочет «соскочить с 1С». Сначала купил книгу по С++ и полностью всю ее прочитал. Даже сделал парочку ВК для 1С, что бы материал закрепить. Потом забросил… Далее решил заняться Джавой и прошел курс ДжаваРаш, написал парочку мобильных приложений… и тоже забросил. Далее нашел какую-то систему по аналогии с 1С, но где программируют на JavaScript — поставил, крутил, пробовал что-то дорабатывать… В общем прошло уже несколько лет, а он как работал программистом 1С, так ничего в его жизни существенно не изменилось. И да, ему тоже платят хорошую зарплату и его основная мотивация была только в том, что бы «сесть на трактор».
1) Вы предлагаете снимать программу с поддержки и писать данные по конфигурации напрямую в конфигурацию. Для Бухгалтерий, которые регулярно самостоятельно обновляются без участия «программиста» — это не выход из-за поломки такого автообновления и вам выше правильно напомнили про возможность создать сервис с помощью расширения, который будет выдавать нужную информацию.
2) И еще вы совершенно верно указали, что названия таблиц при реструктуризации изменяются. Так от куда у вас взялась идея, что ваша таблица с метаданными ВСЕГДА будет называться _InfoReg27083? Ее название тоже может легко изменится при обновлении, когда изменится состав дерева метаданных (или при переходе на новую версию платформы). Т.е. вместо того, что бы просто брать готовые данные, вы сами себя обрекаете на перепроверку и возможное переписывание ваших скриптов для каждой из попыток загрузки.
*) И сколько можно про русский язык? Если вы не знаете русского языка, то пишите код на английском. Есть целые линейки программ из серии «1С: Предприятие», которые ориентированы на внешний рынок и написаны полностью на английском языке без единого русского слова (есть даже две типовые конфигурации, которые пишет сама компания 1С, а не ее партнеры — Small Business и Accounting Suite). Вот только на русскоязычной территории СНГ и ближнего зарубежья (Прибалтика, Молдова и пр.) предпочитают именно русский язык и это является конкурентным преимуществом при распространении.
То, что вы описали как четыре минуса для получения данных с помощью стандартных средств 1С (SOAP, OData или HTTP-сервисы с XML/JSON), вообще к ним не относятся.
Расписания выгрузок/загрузок и прочая «роботизация» находится на вашей стороне, а 1С при таком подходе выступает как сервер данных: вы сделали запроса и получили ответ. Формально это даже не минус, а просто реалии вашей работы как «ETL-специалиста» с любым источником данных.
Что же это за особенности? У меня уже есть ряд мобильных разработок для удаленной работы с базами 1С и они работают довольно шустро даже в сценариях, когда требуется полная и актуальная НСИ. В первом варианте происходит быстрая выборка, сериализация в нужный формат и возврат веб-сервером. Во втором варианте перед запросом нужно каждый раз актуализировать информацию по меппингу и только затем уже можно выбирать данные и преобразовывать в тот вид, с которым вы будете далее работать.
В первом подходе никаких изменений вносить не требуется, а при непосредственном доступе к СУБД из-за изменения структуры и названия таблиц эти изменения постоянны.
Тут даже комментировать особо нечего. Весь контроль целостности находится на стороне платформы, которая гарантирует в 99,9% случаев успешные чтение и запись (еще есть редкие случаи сбоев самой СУБД на которые 1С влиять не может). А вот бездумный INSERT/UPDATE/DELETE напрямую в СУБД может натворить делов… Но вы же в статье только про получение информации говорите? Тогда какая к черту целостность? Скорее тут вопрос в согласованности данных! В режиме 1С вы получаете гарантированно цельный и согласованный объект, а в режиме СУБД можете напутать с версиями и JOIN-ми табличных частей. Не говоря уже о том, что легко нарваться на грязное чтение.
А вы не хотели бы осветить работу со стандартами более широко, возможно в виде статьи? Тема интересная, особенно в свете ваших слов «Потому, что с 2008 года во всем мире ВСЕ процессы (в том числе и абсолютно все бизнес-процессы) построены по готовым стандартам.»
И тем не менее гугление по вашему стандарту IEC 61512 выдает именно ГОСТ Р МЭК 61512-1-2016, который создан на базе IEC 61512-1:1997