Pull to refresh

Comments 149

В 1С: УТ (КА или ERP) можно сразу вести номенклатуру поставщика, которая сохраняется в соответствии с собственной номенклатурой. Причем сохраняется и вся динамика цен разных позиций разных поставщиков которую можно использовать в маркетинге и ценообразовании, например для составления правил формирования цен по ценовым групам (средняя по прайсам поставщиков, самая низкая из всех поставщиков плюс 3 % и т.п.) и потом использовать это все подборе при заполнении заявок клиентам.


ВПР — это круто, но только если надо разово что-то свести, а для решения вашей задачи уже есть отработанные и хорошо документированные механизмы.


Как частное решение — это круто.


PS. Заявку на 100 позиций делать за 30 минут — это пипец долго.

а в обычной 1С УТ 11 например такой есть механизм? и с почты умеет вытягивать и распаршивать XLS?
а зачем? есть криптопровайдеры с защищеной верифицируемой почтой например тензор и т д, который обменивается накладными напрямую база — база через обработку.

А обычной почтой можно легко подменить письмо.
а если таких поставщиков 20, и они не пускают в свои базы, а только на почту шлют? )
А зачем кого то пускать?
У них настраивается, что для такого то контрагента накладные уходят автоматом при запуске обработки обмена. Накладные подписываются цифровой подпись и уходят криптопровайдеру. Потом запускаете у себя и они приходят к вам. Причем этот обмен юридически значим и безотзывен.

Например, где я работал 50% контрагентов с 90% оборота ходили так.

Знаете как это упрощает документооборот. Не нужны бумажные документы от слова совсем.

Так как отчетность в налоговую все и так отправляют электронно, то сбис или тензор или что то еще есть уже.
Интересно, а есть такое же, только для счетов? Большинство до сих пор используют бумажные счета или pdf, информация из которых перебивается в 1с руками
Есть. Добавляется учетная запись одного из операторов документооборота и можно счетами бросаться через него.

Все это езжено изъезжено, описано в официальной документации, сняты сотни видеогайдов на ютубе, и тысячи частных доработок на инфостате.
Парсить из почты я не видел, но просто парсить — да, это часть механизма. Загружать можно при поступлении товаров и просто так отдельно, вести можно цены поставщиков и цены конкурентов.

да, можно и парсить сразу xls при получении письма. хз, прикольно, конечно, но уже есть готовые продукты.
А можете привести пример? Тема интересная.
Я знаю Talend ETL (со своими ограничениями), ну и просто на питоне парсить.
Лет 10 назад, тоже автомотизировал работу отдела продаж, у них 20 позиций в заявке в среднем 25минут оформляли
После автомотизации некоторые личности за 8 секунд стали такую заявку оформлять (на конкурентные товары им получалась больше премия)
И уволили они потом в сумме человек 20 из отдела в 24 человека
А потом все равно новых наняли, правда уже на каждого продажника было не по 15клиентов, а по 100-120
Я думал уже эти вопросы давно решены, если не компанией то конкурентами
А факт что нет, показатель видимо недостатка конкуренции в отрасли.
Автор мог бы свою компанию открыть и заработал бы больше
Это очень быстро, говорю как менеджер по продаже радиоэлектронных компонентов. В нашей организации заявка в 100 позиций может обрабатываться целый день. Одна заявка — один менеджер на ее обработку к сожалению вручную.
Подобно, я показал как секретарю работать в ворде и ускорил ее работу в 10 раз.
1С: УТ (КА или ERP)

Следующим этапом можно будет выгнать 90% продажников, ибо 10% будут справляться со всеми заказами.


А вообще, день на обработку заказа — это ад. И если начальство никак это не пытались это исправить, значит в компании что-то не так.

Наборот, продажники теперь могут заняться продажами. От мосигры есть хорошие статьи о том, что продажник — не робот выдающий.
Интересно, как поменялась жизнь продажников на заводе автора?
Это выглядит неплохо для форума по маркетингу. Если никто на этом форуме в маркетинге не понимает примерно ничего. В формате Хабра это просто несерьезно… Вы действительно собираетесь здесь формулы excel обсуждать? Вообще-то, для подобных целей человечество придумало базы данных.

Единственное, что в этом опыте было бы сколько-то интересным — это merge, алгоритм признания внешне разных товаров одинаковыми. И — sic! — механизмы обработки ошибок, в том числе — false positive. Но вот именно об этом не написано ничего…

А 30 минут — это совершенно не достижение. Должно вообще клиенту в реальном времени цены отдавать.
Примеров — горы, часто разговор о десятках и сотнях миллионов позиций, и обрабатывают это вовсе не суперкомпьютеры, а как бы не VPS за 5 баксов в месяц.
По-моему, статья скорее про то, как с помощью имеющихся ресурсов за короткое время сделано существенное улучшение.

Потому что правильную систему надо покупать/разрабатывать и внедрять, это много времени и денег — а руководство может и не выделить столько. А когда уже есть существенное улучшение и пользователи его с руками отрывают, то и деньги легче найдутся, и внедрять легче будет.
Нет проблем. но это никак не может быть темой для статьи на профессиональном ресурсе. Как выше справедливо написали — обучил бы девочку документы в ворде печатать, а не писать от руки — это тоже стало бы очень существенным улучшением, только вот тема такая для хабра не подходит никак.
Есть техника сложная, есть простая. У сложной техники цена высокая, у простой — низкая. У простой техники есть свои преимущества. И писать про простую технику сюда считаю правильным.
Я на 146% уверен, что сделать (если не умеешь сам — нанять за копейки фрила) нормальный вариант — с бд и простейшей мордой хоть на PHP, было бы дешевле, быстрее, результат был бы более поддерживаемым, работало бы все мгновенно, а не 30 минут и пр, пр, пр.
Результат труда фрилансера за 3 копейки — быстрее и надёжнее? И легко поддерживать?

Всё же не соглашусь. Формулы и «администрирование» тиражного продукта поддерживать гораздо проще и работает это гораздо надёжней, чем наколенная поделка Васи.
Да. Безусловно. простой пример: достаточно в любом прайсе допустить ошибку (или как-нибудь криво изменить название) — и все, надо править регулярки и формулы. Понятно же, что на любую регулярку можно найти false positive, да?

В то время как простейшая поделка, разбивающая описание на токены и сравнивающая расстояние, скорее всего будет и дальше работать с каменным лицом.
В 1000 раз быстрее.
Нас рассудит только двухлетний эксперимент по эксплуатации двух вариантов в схожих организациях. Всё остальное — бессмысленный разговор.
А можно немного развернуть ваше предложение или дать название алгоритма?
Да вариантов миллион…
Например:
«Телефон сотовый Nokia 3310 серый GSM» -> [«Телефон», «сотовый», «Nokia», «3310», «серый», «GSM»]. В идеале — еще и нарисовать таблицу трансформации токенов (серые->серый, нокия->Nokia, GSM->LTE и тд)
Этот набор индексируем чем-нибудь навроде sphinx (а можно и не париться с разбиением). а потом просто ищем в индексе. сфинкс покажет процент совпадения.

Если хочется теорий — гуглите по ключевым словам «редакционное расстояние», Левенштейн, Вагнер-Фишер.

Вы программист, который не понимает клиентов.
Пожелаю вам удачи, прийти к руководству завода и предложить заказать PHP script на freelance у никому неизвестного исполнителя.

Спасибо за комплимент. Если б написали еще и «молодой программист» — я был бы совсем счастлив.

К руководству завода с похожими предложениями я впервые пришел в 89 году. Но годы летят, и вот уже лет 25 с идеями к руководству не хожу.
Но, чувствую, стоит начать! 8-)

А вы всерьез считаете, что пользоваться невнятными скриптами продажника — это круче? И у руководства — если что — найдет большую поддержку?
Вы никогда не видели сайтов заводов, сделанных фрилансерами? У них, наверное, инициативного продажника не нашлось, ага.

А главное — нам всем очень не хватает их опыта тут, на хабре. И не дай Бог, хоть строчку кода напишут! Или формулу хоть одну! так и надо: «я сбацал очень клевый сайт. Но код не покажу, адрес не дам, про структуру ни слова. Но пасаран.»

Моя позиция в этом вопросе — не связываться с заводами )

А я вот, наоборот — призадумался. Это ж какое поле для деятельности!
Кроме шуток, ситуация абсолютно аналогична той, с которой я начинал 30 лет назад! Ну задачи чуток другие были, заовд оборонный, клиентов на стороне нет, но метода та же самая: бланки, их ручкой заполняют, переписывают из других бланков, ошибаются, «крыжат», «сводят» — и буквально любое телодвижение в сторону автоматизации ускоряет дело в какое-то невероятное количество раз.

Как-то странно думать, что рынок для таких экзерсисов есть и сейчас 8-)
А ведь была у меня когда-то (активно воруемая) программка автоматизированной обработки прайсов на Access95, емнип… Этакая мельница: что ни кинь — выйдет мука заданного сорта. Но бросил лет 15 назад, подумал — нет рынка, уж теперь-то у всех этот вопрос решен. Оказывается — нет!
Но бросил лет 15 назад, подумал — нет рынка, уж теперь-то у всех этот вопрос решен. Оказывается — нет!

рынок есть, но как вы думаете сколько вам готовы заплатить за такую автоматизацию?
Это так не оценить.
Если речь про публичный сервис-автомат, то это будет недорого, поскольку потребляемые ресурсы незначительны. Но можно брать массой.

А сколько готов заплатить бизнес — тут все зависит от того, есть ли сейчас хоть один конкурент, который всех делает как детей одним фактом мгновенной проценки и отгрузки. Как только хоть один такой вариант у покупателей появится, так сразу же сознание владельцев конкурентов начнет вмещать очень существенные суммы 8-) Вплоть до сотен тыр разово + помесячное обслуживание.
в большинстве случаев анрил, если они в 18 году до этого еще не дошли то проблема уже структурная

внедрение даже подобной системы это десятки человекочасов с боем с сопротивляющимся отделом, а «очень дорого» (с)
понятно, что структурная. Но я такое видел не раз. подобные «взлеты с BC в XVI век» делаются сверху. Просто придет новый начальник, ужаснется, и создаст группу рядом. Там ведь много народу не надо… и как только новая заработает — старых разгонят.

Да, есть сложные процессы, которые действительно долго, дорого и сложно автоматизировать. Но — не этот.
Просто придет новый начальник

вот это тут самое главное
другое дело что нормальный начальник в 18 году будет нормальную ERP внедрять, а не костылики вместо экселя строить
Внедрять? Нет. Он будет ныть, на ковре у правления, например, или совдире. А внедрять будет IT + интегратор, когда/если решение окажется положительным. Сильно потом, и совсем не то, что продажникам надо. И легко может оказаться, что автоматизируют все, кроме вот этого тупого перемалывания прайсов, потому как в коробке его нет, надо дописать коннектор, а подрядчик тупит, а когда выкатит — работает не так, а потом формат поменяется и вообще все надо будет переделывать… так и живем на экселе 8-)

Так что, вариант покупки сервиса за 300-500-999р/рабочее место/месяц — своей властью, внутри отдельского бюджета — выглядит вполне жизненным.
А внедрять будет IT + интегратор

без начальника, IT + интегратор ничего не внедрят, к томуже я представляю себе ИТ отдел завода, три Василия с зарплатой 5000р вешающих сопли на свичах из магазина

тут как раз проблема в начальнике как источнике движущей силы этого процесса, выбить бюджет+тащить интеграцию
Интегратору то пофиг, ему бабла заплатили, а на территорию не пустили он и уехал… как внедрять месяцами можно
Мы тут в одной конторе элементарный EDI для выгрузки счетовфактур внедряли два года тупо потому что всем какбы-ответственным наплевать с высокой колокольни… при этом бабло было заплачено за весь процесс
Нормальную это какую? Как начальник распознает нормальную? Как поймет что внедренцы адекватные?.. Тут уже сейчас как минимум два внедренца, которые вообще не собираются вникать в суть проблемы а пишут радужные посты типа это все уже решено до Вас остается только пригласить нас.

Абсолютно согласен, иногда вообще достаточно изобразить схему процесса целиком (даже от руки), проанализировать каждый этап, связи, после этого, станет ясно, что и как можно автоматизировать, ускорить, выбросить.

Статья в топе на первом месте, значит многим это интересно. Так что не нужно делать выводы за весь хабр о том, что данная статья для него это не серьёзно.
Дык! Тема мне тоже интересна — я тоже зашел.
Другое дело, что даже беглый взгляд привел к разочарованию…
А минусы ставить я не люблю — человек все же старался.
Вот и топ…
Не но плюсы тоже есть у статьи. И много.
Да, я тоже удивился.
Но вот серьезно: неужели хоть кто-нибудь, претендующий на какой-то минимальный профессионализм в IT, мог найти в этой статье хоть что-то новое для себя?
В постановке задачи есть надчем подумать. Очень часто программные продукты рассчитаныина некие идеальные условия которые существуют только в головах разработчиков. Особенно это касается производства. Где большая номенклатура продукции и применяемых материалов.
И где тут постановка задачи?
Больше того: уверен, что доля ручного труда осталась немалой, личное участие автора для функционирования системы необходимо, вероятность ошибок велика, и они обрабатываются примерно никак.

Я б тоже с удовольствием почитал не про реализацию неизвестно чего на уровне курсача техникума, а про теорию. Поскольку сам занимался этим вопросом в свое время, и точно знаю, что тогда на 100% задачу не решил 8-)

Простой вопрос: что делать с позициями, которые ни в одну из регулярок не провалились? Хоть какой-то список на review выдается? А его кто-нибудь когда-нибудь смотрит? 8-)
Что, если на каком-нибудь заводе перепутают колонки с ценой и количеством? Или убьют кодировку? Или формат числа в колонке цены? или случайно поставят себе курс 1$=3 рубля? Так вот и будут всем счета выставлять по 3 рубля рублями, да?

Вот если бы статья была про это — я б тоже поставил плюс. А кто их ставит сейчас — представления не имею.
Постановка примерно такая. Есть заявки в форме электронных писем, факсов, текста, pdf, сканов документов. И есть кроме своих столько же прайсов поставщиков в такой же форме. Необходимо однозначно сопоставить цены в прайсах с номенклатурой заявок.
Это цель. А задача, которая тут решалась — окучить исходные данные и подготовить их к максимально быстрой обработке. Кстати, с большой вероятностью, решение этой задачи позволит примерно так же обрабатывать и входящие блоки — там тоже наверняка черт ногу сломит.
отличный пример, как решение собранное на коленке сильно облегчает жизнь людей без внедрения тяжелых решений. коэффициент Цена/Качество просто зашкаливает ))
Решение офигенное по КПД — с минимальными затратами реализован функционал, приносящий прибыль.
А точнее — не приносящий столько убытков.
Завтра появится примитивный стартап, обсчитывающий любой запрос в онлайне, безгеморно отгружающий и тп — и все подобные формулы будут списаны в утиль.
Серьезно говорю, я такое видел не раз.

У меня недавно перед глазами прожект прошел про радиодетали — так там конкуренты миллисекундами меряются. А базы колоссальные, сотни миллионов позиций. Уверяю вас, никто суперкомпьютерами не пользуется 8-) так, впски по 500р в месяц. А вот расстояние в ДЦ играет реальную роль, прямо и недвусмысленно отражаясь на продажах.
Где колоссальные базы — там прайсы от производителей тоже (как и в описываемом автором статьи случае) идут в виде случайным образом форматированных xls файлов? :)
Или всё-таки через API отдаются?
Вот чего не знаю — того не знаю. Я видел уже готовые базы.
Хотя, зная modus operandi китайских производителей (а радиодетали — они же все из китая, да?), могу предположить, что случайно форматированные xls-файлы — это только у самых культурных. А наверняка найдутся и те, кто только по телефону прайс озвучивает 8-) ну или могут сканы в pdf прислать.

Но у людей там в любом случае есть проблема ровно того же порядка: надо помэпить пользовательский запрос (который, ясно, может быть любым) на имеющуюся номенклатуру. И сделать это не за 30 минут, а за десятки msec, максимум — сотни. Если больше — пролет.
Вы существенно улучшили техпроцесс компании, отразилось ли это материально на вас и коллегах? Оценил ли это работодатель премией, или допустим вы стали эффективнее и поэтому ваш доход стал выше?
во-первых, наверное, стало проще работать, во-вторых, опыт. выводы насчет работодателя уже всем понятны, а возможно и оценили каким-либо образом
Материально, конечно отразилось — выросла выручка всего отдела, а за ней и ежемесячная премия
Нейросети и регулярки, это круто. Наверно.
Но лет 15 назад у меня была задача сопоставления наименований товарных позиций различных поставщиков. Я не знал про нейросети тогда, поэтому вынужден был применить нечёткий поиск. N-граммы работали на ура, выдавая подобные наименования, отсортированные по степени близости к исходному. Не в Excel, конечно, но в Access это работало на ура.
Алгоритмы на основе триграм, levenshtein distance или match against бд вероятнее всего, будут эффективнее чем 10 регулярок, упомянутых, но почему-то не присутствующих в статье. Я не специалист по нейросетям, можете пояснить, они подходят для такого рода задач?
На самом деле в моём комментарии присутствует огромная доля сарказма. Математика триграмм ничтожна по отношению к регуляркам, а тем более нейросетям. Микроскоп и гвозди, это вещи, которые нужно хранить и применять по отдельности.
Да, подходят: DSSM. Можно вложить названия товаров в пространство, а потом поискать в этом пространстве похожие вектора. Разумеется, нужно много обучающих примеров.
Возможно такое ускорение связано с тем, что с помощью новой системы продажники и/или снабженцы стали в 20 раз быстрее получать свои «законные» откаты.
В таком ракурсе Вы не рассматривали?
Я не из робкого десятка, но читать жутковато. Представил, как разверзлась земля — а оттуда голос: «Нужно просто свести все прайс-листы в одну большую таблицу» и демонический смех.
Это тянет на отдельную статью, кстати

… что и делается яндекс маркетом, price.ua и другими розетками и онлайн магазинами-перепродажниками..

Онлайн на то и онлайн, что работа по обработке прайсов поставщиков проводится до(!) попадания клиента на сайт. Кто-то их парсит с чужих сайтов, кто-то формализует и собирает напрямую через api и т.д.
А в данной статье мы видим частичку закулисья самых адских контор, которые начинают шевелить мизинцем ноги и что-то там кривыми костылями ускорять уже после заявки клиента с номенклатурой. Я вообще не знаю как они пока что выживают с таким подходом.
с одной стороны отличное решение в стиле спасение утопающих — дело рук сами утопающих, с другой стороны рассказывать программистам, знакомым с СУБД, о программировании под Excel это как то не очень.
Но с точки зрения эффективности — затрат рабочего времени (стоимости рабочего времени) в отношении к полезному эффекту — очень крутое решение, если бы эту задачу решал программист, то обошлось бы в разы дороже.
Постоянно пользуюсь Excel для прототипов. Пишу рекурсивные функции, строю графики, проверяю ошибки. Особенно в задачах моделирования и симуляции, абсолютно необходимый инструмент.
Автору респект как инициативному работнику. Я тоже очень долго работал в конторе не в ИТ отделе, но обладая некотороыми заниями в ИТ. Что касается этого пути с Excel. Поверьте мне, электроные таблицы предназначены для быстрого составления отчетов которые помещаются на один экран. Положительный эффект от Excel сильно уменьшается с объемом таблиц, с количеством таблиц и с тем насколько долго эта система эксплуатируется. Через лет 5-10 работы (и даже раньше) приходится чуть ли не каждую цифру с калькулятором проверять потому что пока работник который что-то знал был в отпуске, с таблицей работал работник которого не жалко. Он добавил пару строк или столбцов в результате где-то сместились формулы, какие-то формулы забыли скопировать, а добавленные в конце или в начале строки не вошли в итоги.

Так что по хорошему нужно чтобы ИТ-служба это все отработала. Хотя там тоже могут быть проблемы. Если там нет хороших разработчиков на Вас может свалиться некая самописная «ЕРП» с которой будет работать настолько удобно что вы будете готовы считать на счетах.
Спасибо! Тут полностью согласен — использовать Excel для работы с таблицей больше 25 000 строк, стало очень непросто. Возможно дело в том, что я недостаточно занимался оптимизацией логики, но это уже другой разговор. Вообще, про Excel упомянул только чтобы показать через что пришел к своему решению, а так, вся логика давно на App Script.
Попробуйте Power Bi.
Да и в целом Вам лучше смотреть в сторону механизма выборки из массива, можно и из гугл-таблиц данные подтягивать.
Ведь всем не нужны ВСЕ данные, достаточна малая часть.
Ну а потом, опыт подскажет прямой путь в настоящие БД…

https://www.youtube.com/watch?v=fIf7c49iiIk
Чудеснейший пример как на Python + Pandas можно заменить примерно треть функционала БД с достаточной скоростью.


http://edu.skillfactory.ru/excelpython
Повтор будет послезавтра.


И да, это не реклама скиллфактори. Просто редко встречал адекватного человека из Р*****ома, а тут он еще и интересно рассказывает на достаточно реальных примерах.

Интересно, какие у вас были зарплаты и каких денег стоили эти счета, если руководство могло позволить себе потратить 2 человеко-дня на представления предложения покупателю
На самом деле статья о том что кое-где в России по-прежнему каменный век. И на ИТшника там смотрят как на мальчик-поменяй-мышку.
До тех пор, пока он не показывает, как делать их работу в 20 раз быстрее чем они.
Тогда его начнут ненавидеть и сольют при первой возможности.
Я наблюдал два варианта развития. Первый положительный когда работника начали ценить и продвигать по служебной лестнице со сказочной скоростью. И второй когда работника все же не сокращали первым соаратом. Но на него ложился совершенно дикий объём работ при этом его все считали ниразу не специалистом.
Это всё очень вперчатляет! Велосипед пару раз изобретён и классические грабли собраны, но так продвинуться вперёд самостоятельно — это реально круто.

Я не согласен с советами про ERP, если предприятие этого ещё не сдалало — не в Ваших силах это изменить. Это как совет «станьте ежами».

Я подобные задачки решал несколько раз, поэтому хочу дать пару советов:

1. Утащите все данные в Google BigQuery. С одной стороны, это сервис внутри гугловой инфры, Google Sheets умеют из него писать и читать. Не придётся миргировать всю систему за раз. С другой стороны, это настоящая база данных с масштабом, SQL, клиентами под разные языки программирования и т.п. Работать будет за секунды, даже не за десятки.

2. Утащите всю логику в SQL на BigQuery. Иначе через пол года сами утоните в своих функциях. Вы, конечно, не послушаете. Но как уже утоните, тогда будете знать куда мигрировать.

3. Я правильно понял, что цены поставщиков меняются часто, а набор товаров — редко? Уже советовали вверху — нужно разделить задачи поиска актуальной цены и задачу матчинга товаров. Введите свой стандарт написания и свою номинклатуру товаров. Все товары поставщиков сматчить один раз к этой номинклатуре. Далее использовать эту таблицу индексов для поиска цены (DB & SQL — никуда без этого).

4. Учитесь кодить на питоне. Под эти задачи очень подходит. Он сможет работать с базой данных и слать туда SQL. Плюс при желании настроить нейросетку — вот они библиотеки, все рядом.

5. До нейросетки стоит попробовать n-gramm. Или уже делали? Ещё хороший контрольный признак — это разброс цен. Если алгоритм сматчил товар за 100 руб и за 10000 руб — что-то явно не так.
Благодарю за советы!

По 1, 2 и 3 пунктам — в целом в эту сторону и планировал двигаться. Спасибо, что окончательно убедили.

4. По питону — понял, буду учить.

5. n-gramm делал, но он мне не совсем подошел — а именно, я хотел чтобы система точно понимала какой признак определился, длина или например диаметр. А так как в описании иногда бывает много мусора, то все перемешивалось. Возможно как раз контрольный признак меня спасет, так что есть повод вернуться к этому
Учите лучше 1С. Продукты на платформе 1С сердце любого предприятия, и ваши навыки пригодятся вам и в других задачах. При этом изучение 1С на порядок проще питона (т.к. платформа 1С это сразу и среда разработки и СУБД, плюс много готовых решений которые делают примерно то что вам нужно).

Просто как пример: infostart.ru/public/596761, infostart.ru/public/754248
Советы про ЕРП не зря — много раз видел людей сидящих на 1С торговле и использующих её только для подготовки печатных документов и контроля склада. А ведь там есть регистр «Номенклатура поставщиков» сделанный как раз для сведения к единой позиции всех вариантов уже давным давно. Но он сделан настолько не бросающимся в глаза, что мало кто его использует.
Так что вполне возможно, что и у автора 1С есть. Только в неё вносят тот самый подготовленный автором счёт после оплаты в документ реализации. И опять руками.
Утащите все данные в Google BigQuery.

Предварительно посоветовавшись с безопасниками, ага. А то предприятия — они разные бывают. С разными подходами к "хранению информации в сети Интернет"


Утащите всю логику в SQL

Правильно. Чтоб потом понимать, почему именно больше никогда-никогда не пытаться реализовывать логику в SQL.

Ну, в данном случае данные уже в Google Sheets.

Про SQL и не начинайте:) Для каждого инструмента свои задачи. В моём понимании его задача — это по большей части именно SQL.
На мой взгляд для решения описанной задачи очень подходит 1С.

Особенно она подходит менеджеру который не собирается становиться программистом. Так же как выше заметили полно обработок решающих подобные проблемы, бери любую и дорабатывай под себя.
Порог вхождения в разработку на платформе очень низкий, при этом 1С уже есть у них так что покупать ничего не нужно.
спасибо за очень интересный опыт в Вашей статье, входные данные Вы брали только эксель и 1с?
Данные по прайсам поставщиков беру из Excel, csv и xml. По собственному производству и складу из 1С.
может кто-то еще поделится своим опытом решения подобных задач либо готовые продукты которые могут это все делать?

чисто с обывательской стороны интересно, как можно ускорить/автоматизировать и т.д. подобные задачи.
Задачи все решаемы, но лучше сначала уточнить место приложения усилий. Например, в данной статье клиент пишет заявку, не зная конечной цены товара. Потом некий персонал в мыле обрабатывает заявку, уточняет-выясняет-ставит цены и отправляет клиенту счет с ценами. Клиент смотрит на счет и принимает решение о покупке исходя из цен в нем. По моему опыту, при таком подходе, за этим счетом следует уточненная заявка от клиента и еще один счет. Все при деле, когда на сайте компании «цена по запросу». Емэйлы летают, бумаги печатаются, эксели кипят
Странно, как Ваш завод вообще работает. В Exel учет ведут… Государственный что ли?
Завод давно не государственный. Не пойму почему вы решили что мы весь учет ведем в Excel. Учет раньше велся в 1С, сейчас переходим на ERP
1С ERP. Раньше была 1с8, но она была полностью самописной быстро, да еще «на коленке», поэтому вести управленческий учет было практически невозможно и в руководстве решили, что проще новую заказать
Тогда вы основная проблема автоматизации организации, так как делаете удобной работу не в общей базе, а в экселе ускоряя отдельные этапы, но делая общую производительность намного хуже. Вместо того что бы переделать номенклатуру один раз и выделить человека для заведения НСИ, вы продолжаете автоматизировать хаос.
Я просто ждал эту фразу в обсуждении. В класическом варианте она звучит так: «Бардак автоматизироать невозможно». Я ее воспринимаю как нежелание решать действительную проблему в управлении организацией, а предлагать решение которое легче всего реализовать и более того которое уже реализовано в станрдартной конфигурации 1с или в ERP.

Ну будет НСИ. Скорее всего есть уже эта НСИ. Какое это отношение имеет к разбираемой проблеме. К тому что приходит заявка факсом или прайсы в сканах.
Вы и в рамках данной статьи ничего не сможете сделать с прайсом в сканах.
Так что, ответ простой: любой вход переводится в электронный вид, если надо — вычитывается, приводится в принятую внутри компании номенклатуру, и либо проценивается, либо принимается в качестве источника данных.
А если к 1С прикрутить решение 1C-B2B то можно еще в разы ускорить обработку заявок от клиентов ;)

Браво!!! Аплодирую стоя!
В далеком 2002-ом я делал нечто подобное. Оказывается, проблема автоматизации ручного труда еще актуальна :-(

Благодарю! Проблема не то, что актуальна, судя по тому, что мы в разы опережаем по скорости подготовки предложений большинство конкурентов — такое ощущение, что над ней даже работать не начали. По крайней мере, такая ситуация сейчас в нашей отрасли. Иногда мне удается пообщаться с руководством заводов по выпуску схожей с нашей продукции, и когда я рассказываю им о том как работает наш отдел продаж, выражение их лица резко меняется, глаза округляются, а я в их глазах видимо становлюсь профи-программистом, хотя сам и понимаю что даже далеко не джуниор.

Фокус в том, что вся эта оптимизация действительно выглядит как простая фигня, которую может сделать студент. И да, она будет работать и прям сразу давать профит.
В долгосрочной же перспективе получается, что сейчас все привыкнут к этому процессу, а когда вы уволитесь — то всё повиснет в состоянии "ЗАМИНИРОВАНО". Т.е. будет работать до первого сбоя, а тогда вообще всё встанет раком и, возможно, надолго. Потому что все привычные (до этого момента) процессы позабыты/заброшены, а новый перестал работать и чинить его некому.


Тогда встаёт вопрос о каком-то централизованном решении — подрядчик, например. Который разрабатывает и внедряет. А это разом другой порядок расходов.
А подрядчик не дурак — он захочет не одного клиента окучить и будет рожать универсального монстра, который бы подходил всем


И тут мы получаем ещё одну 1С.


В общем бизнесу бывает просто страшно менять текущий процесс, потому что он более-менее справляется, а большего и не нужно.

«то всё повиснет в состоянии „ЗАМИНИРОВАНО“»
А вот я за то? чтоб оставить Так «как есть» (AS-IS).
А то знаем, турнут потом после идеальной «неоплачиваемой» отладки и два года оно будет крутиться вполне сносно. А ты крутись как хочешь.

Автор. Оставь так, а все дальнейшие улучшения только на тестовой удалённой машине, к которой доступ только у тебя. Как отладишь методу продать внедрение и поддержку через «знакомого программиста» своему руководству, а потом и «соседним» заводам.
т.е. вы хотите сказать что нормальным разработчикам стоит попробовать походить по подобным фирмам и предложить им улучшение их жизни? Или таких предложений вагон и это просто самодурство собственников и директоров?
Стоит однозначно. Но для этого нужны не только навыки в разработке, но и навыки в умении разговаривать с руководством и сотрудниками подобных фирм. И сначала понять, надо ли такое улучшение кому-то в этой фирме. А то может оказаться, что начальник отдела продаж не хочет, чтобы сотрудников под его началом стало в 20 раз меньше. А начальнику просто пофиг, так как продажники, которые делают предложения из экселя — народ дешевый и много тут не сэкономишь. И тогда этот проект может стать кошмаром для внедрения: пофигизм плюс саботаж.
Проблема в том, что в большинстве случаев эфективно решить задачу можно только пощупав ее изнутри. И в топике именно такой случай — специалист по продажам с толикой знаний в разработке ПО прочувствовал все нюансы и выдал решение, наилучшим образом приспособленное к ее решению. В противовес этому — я многократно видел как клиент приходил, и вроде-бы нормально ставил тз профессиональным разработчикам, но т.к. разработчики понимают задачу только в рамках тз, результат остваляет желать лучшего в плане юзабельности и это выливается потом в тонны дополнений и исправлений.
А я — в 89. Тогда были магические слова «расчет зарплаты».
В 2002 уже давно работала самопальная ERP, которая для начала разговора сгребала все прайсы в базу и трамбовала, смердживая на основе полу-самопального полнотекстового поиска. Клиенты уже могли пробить свои хотелки через веб-интерфейс в режиме онлайн.
Надо объявить перепись: кто раньше? 8-)
тут больше проблема в начальстве, которое просто сидит на жопе ровно, т.к. «продажи идут»
Оффтопик, возможно, но почему завод не может единую классификацию выпускаемой продукции ввести вместо всей этой эвристики? Или у вас таки не завод, а оптовый склад?
То, что я описал в статье, это часть комплексного процесса обработки заявки:
Чаще всего заявки включают не только инструмент который мы изготавливаем сами, и заказчики очень не любит их делить между поставщиками, поэтому мы вынуждены непрофильную продукцию закупать на стороне.
Описывать как мы заводим заказы в 1С я понятное дело не стал, а рассказал о другой части процесса.
В том то и вопрос что сначала нужно определить какую задачу решать а потом уже решать. Вопрос в том что одна и та же позиция в номенклатуре может в прайсах и в заявках называться совершенно по-разному. И это исходные условия. Это внешняя по отношению к предприятию информация. И наоборот две позиции которые называеются пркатически одинаково (разница 1% текста) на самом деле совершенно разные по содержанию т.к. этот 1% может касаться или точности или материала или покрытия. В реальности есть специалисты у которых обработка заявок как битва за урожай. С другой стороны разработчики которые уверены что если создать справочник инструменты и поставщики а также документ прайсы то все проблемы будут разрешены. А также администрация которая вынуждена привлекать или сторонних консультантов которые как правило (даже самые лучшие и независимые) продвигают некоторый близкий их бизнесу продукт. Или же (что не немного лучше) штат собственных ИТ которые зачастую те что остались, и собираются сделать это все «на Делфях». Вобщем ситуация очнь непростая.
Я для того ссылку и привёл, что
1. ЕРП уже внедряется на предприятии автора. Желательно, чтобы инструмент использовался наиболее полно, иначе будет больше проблем, чем выгоды.
2. Если вы приглядитесь, там в регистрации для номенклатуры две колонки — номенклатура (то, как эта штука называется у нас и проходит по складскому учёту) и номенклатура поставщика (то, как эта позиция называется в прайсе этого поставщика)
Соответственно, загрузка делается примерно так: проглатываем прайс, (колонки поставщик, цена, номенклатура поставщика, возможно спец условия для цены) заполняем известные позиции по колонке «номенклатура» (исторически подобранные), выдаём строки, в которых колонка «номенклатура» не заполнена для заполнения с ручным контролем. И вот там уже специалист (та самая девушка с 10 годами опыта) и смотрит на все важные 1% различия. Если нужно — создаёт в нашем справочнике новую позицию.

Если у нас вдруг и заказчик странный, и в заказе то, как он называет позиции, а не как мы хотим, то и его названия можно загрузить в таблицу соответствия и при получении заказа преобразовать в наши термины. Но это редко.
Главной задачей становится таким образом не разбор синонимов, а поиск аналогов. Так как (особенно во всякой машинерии) болт с большей прочностью, который есть на складе вполне может быть аналогом, а вот с меньшей, как ни странно, тоже может, но это надо отдельно уточнить у заказчика.
Как однако все просто оказалось. По этому поводу есть английская пословица. Человек у которого в руках молоток все проблемы кажутся гвоздями.
1) Автор просто молодец. От него ожилали рутинную работу — он занялся автоматизацией и на минуточку ускорил процес в 20!!! раз. Кроме того после етого етапа зделать полную автоматизацию будет намного проще.
2) Но я всегда говорю что EXCEL ето програма которая наносит наибольший вред компаниям. Она отодвигает необходимую автоматизацию предприятий.
3) Ну и зделаю неблагодарную вещь, дам совет — Бегите с етого предприятия.
а) они в 2018 работали с бумажками.
б) они не поощрили увеличение производительности труда.
На таком предприятии работать безперспективно.
они не поощрили увеличение производительности труда

Понимаете, это специфика. Логика руководителей работает следующим образом.
  • Работник получает процент за выполнение задач.
  • Чем больше задач он выполняет, тем больше денег зарабатывает.
  • За счёт чего он выполняет больше задач — неважно.
  • Факт в том, что он стал зарабатывать больше.

За что же его ещё поощрять?
За то, что поделился решением с остальными? Ну, спасибо, конечно, но это его личное дело.
Работник получает процент за выполнение задач.
Чем больше задач он выполняет, тем больше денег зарабатывает.

Ооо, а это может повлечь за собой эффект Стаханова. дальше снизят процент за выполнение задач, сократят лишних сотрудников и начнут задирать планы оставшимся
Именно на таких предприятиях это чаще всего и случается, где руководству пофиг на мотивацию персонала
Вы совершенно правы.
Но как вы рассуждали бы на месте руководства? Какие меры предприняли бы?
Не хочу защищать описанную вами модель, но готов оппонировать, так как интересен взгляд со стороны.
как руководство я конечно бы сократил отдел и вообще бы обрадовался и таки вложился в нормальную автоматизацию с целью сокращение вообще всей бюрократии
===
а чтобы не разбежались сотрудники надо взяться за организацию мотивации персонала, потому что на любом заводе любой слесарь знает что если работать в три пота то потом будет хуже, посколько менеджмент быстро сообразит что производительность выросла, а зарплата 70тыс для рядового слесаря это выше рынка (можно сколько угодно спорить что это нормально в такой модели, но я сталкивался даже с тем что в цех приходила толпа экономистов и отдел планирования и убеждали слесарей что «физически невозможно столько сделать вы обманываете»)
Далеко не всегда EXCEL приносит вред…
Ведь из-за одной грядки часто нет смысла комбайн заводить…
EXCEL очень мощный инструмент, которым можно решить огромное количество задач… (и готов поблагодарить M$ за него)… И часто нет необходимости наворачивать ERP или подключать 1С…
Не ожидал увидеть в этой статье номенклатуру металлореза. Выходит, мы с Вами коллеги (но уже не конкуренты, я из этой сферы ушёл).
Занимался чем-то подобным, но моя идея состояла в разработке универсального каталога на Excel. Если грубо — вводишь тип инструмента, его геометрические характеристики и применимость по ISO, а таблица выплёвывает ряд подходящих решений разных производителей. Основная головная боль при обработке заявок (и особенно — тендеров) — подбор аналогов, которые у зарубежных производителей именуются совершенно по-разному, порой без какой-либо видимой логики. И моя самоделка заметно сужала поле поиска.
Жаль, что с моим уходом всё это стало ненужным, ибо делал для себя.

Осуждающим: почему-то именно в сфере продаж металлорежущего инструмента я столкнулся с невероятной «чёрствостью» бизнес-процессов. Наверное, это относится ко многим областям, связанным с поставками на наши крупные предприятия. Поэтому уровень автоматизации предельно низок, да и подготовка персонала обычно оставляет желать лучшего, как у поставщиков, так и у потребителей, а «заявка» как правило представляет собой кашу из зарубежных обозначений, написанных кириллическими буквами, неактуальных ГОСТов и просто орфографических ошибок.
Для примера — в одном российском филиале очень крупного немецкого торгового дома (определённо известного автору) есть даже специальная должность: человек днями напролёт занимается вычиткой заявок, поступивших от полевых продажников. А это, извините, 50-60 килорублей в месяц — не дешевле ли автоматизировать процесс?.. Видимо, нет.
Автор проделал очень важную и сложную работу в тех условиях, которые ему достались.
Спасибо за статью.
Отличная статья, спасибо, было интересно.
Вот прям как раз сейчас, в течении последних нескольких дней, кручу в голове приложение для знакомой конторы. Один в один та же ситуация с подбором товаров по поставщикам, только оборудование и инвентарь, около 25 прайсов, обновляющихся ежемесячно. Тема точно актуальная, но 100% решаться должна через БД, вот руки не доходят сесть подумать над парсером экселя в бд, пока что единственное, что в голову пришло.
Вы меня замотивировали, сэнкс)
Напишите пожалуйста статью с вариантами решения. У меня описанная проблема очень актуальна, но я не понимаю какими инструментами её можно решить. По логике автоматически определяя группу товара мы понимаем какими характеристиками этот товар обладает. Зная что мы ищем (длину сверла, хвостовик и т.д.) мы можем распарсить входное наименование на характеристики и затем подобрать по характеристикам 2 или 3 самых выгодных решения (в идеале не только по цене но и сроку поставки и стоимости доставки). Но как это технически воплотить — мне совсем непонятно.
Предложение по написанию статьи годное, может что-то и получится.
По теме как я это вижу — максимально атомарно разобрать каждый прайс и потом при помощи флагов поиска в gui проводить подбор по определенным параметрам. Большую трудность по мне, представляет более или менее однообразный разбор таблиц экселя, которые за частую одна на другую не похожи.
Посмотрим.
Как раз с разбором таблиц проблем нет. Сложность в том чтобы преобразовать строку вида «сверло длинной серии ц/х 12 р6м5» в набор характеристик не прибегая к регэкспам, потому что порядок слов и вообще их наличие под вопросом. А дальше сделать то-же самое для прайса поставщиков и затем сопоставить. Что это должно быть?
Уже после того как написал комментарий, понял, что мы с вами говорим о немного разных задачах, ваша сложнее и по ее решению напрашивается только одно — нейронные сети.
Самое забавное — именно реализацию в коде я решил не включать сразу из-за того что считаю ее вполне очевидной, поэтому и написал:
В случае интереса к этой статье, подробнее опишу работу программы со вставками кода.

Теперь, раз интерес все же есть, возникает вопрос к вам, уважаемые хабровчане — о чем лучше писать:
Как выявить самые эффективные регулярные выражения в зависимости от категории?
Как с их помощью привести прайс к одному виду?
Как сматчить все совпадения?
Или как я устроил разбор однообразных таблиц excel?
Или обо всем по порядку?

И с учетом всех комментариев, стоит ли описывать мое, как оказалось невероятно примитивное решение, или стоит сначала что то поумнее придумать?
Буду благодарен за ваше мнение
Было бы интересно почитать про приведение к одному типу, т.к. то, что предлагали для парсинга мне, это два с половиной десятка экселевских таблиц, некоторые с картинкам, с разным количеством столбцов и, естественно, по нескольку книг в одном документе.
Обо всем по порядку, за исключением разбора таблиц.
Причем, интереснее алгоритмы, чем реализация, поскольку реализаций самых разных — горы, и ваша точно не будет новой и вызывающей, что ли. Просто исходя из результата.
А вот в алгоритмах вы вполне могли выдумать что-то новое и интересное.

С точки зрения сотрудника — это безусловный плюс. Такая инициатива должна приветствоваться. Но с точки зрения руководства, перед расширением этого опыта на весь отдел, необходимо решить вопрос построения на основе этой технологии бизнес-процесса и невилирования фактора автобуса. Тогда станет понятна не эмоциональная, а практическая стоимость данного процесса. Насколько данный бизнес-процесс будет работать независимо от исполнителей и сколько будет стоить его обслуживание, когда автор станет недоступен.


Способность к автоматизации бизнес-процессов на первых порах окрыляет. Но главное не забывать, что автоматизация — это, в первую очередь уменьшение человеческого фактора в процессе, а не уменьшение выполняемой людьми работы.


Другими словами, если мощность процесса возросла с 10 до 100, то должны быть механизмы, поддерживающие эту новую мощность на новом уровне. И если эти механизмы более человеко-зависимы, то такое улучшение стратегически играет в минус.

Реакция на повышение производительности труда у нас и у них.

Россия.
— Я повысил производительность в 20 раз!!!
— Пфффф!

Япония.
— Я повысил эффективность на 2%!
— Офигеть, ты крут, на медальку и деньжат!
Дык, база разная.
В данном конкретном случае (когда до рации заявки обрабатывались куском угля на полях старой газеты) и в 2000 раз ускориться — плюнуть раз, любой студент справится.

А в Японии, когда навнедрено всяких кайдзенов да канбанов по 5 вагонов на каждого человека, 2% добавить — банда сеньоров за год работы зафейлит на раз.
ну почему? Надо просто написать статью про какой-нить Clickhouse, наворотить на плюсах что-нить, нейросетку сваять — и описать тут хотя бы самые общие принципы. Ошибки честно обработать, написать хоть какие тесты. Кода накидать мудреного строк 500…
И тогда, даже если это не даст кратного ускорения, все будут молча обтекать. Ну или говорить: ну ты крут, чувак.

А когда любой представляет, что подобное он бы сделал (чтоб не сказать — делал 20 или 30 лет назад) за пару вечеров в самой обычной базе — ну ессно будет пфф, куда деваться…
UFO just landed and posted this here
Но если честно, хотелось бы почитать статью с настраиваемым сравнением строк.
Частая задача с которой сталкиваюсь это адреса написанные как бог на душу положит.

Хотелось бы поиск в базе автоматически наиболее похожего и т д.
UFO just landed and posted this here
Проблема подобных подборов в большом количестве ошибок.
В вашем примере «Водка таежная» и «Таежная Водка 'Элитная'» вполне могут быть и разными товарами, без контекста этого понять нельзя.
Автор молодец, сам много лет подобное изобретаю везде где работаю.

тут бы сделал так: залил прайсы в базу которую больше всего знаю, например MSSQL. Почти у всех прайсов сейчас есть внутренний код товара в этой организации, а то и два кода… Привязывайся к любому. Получается надо один раз свести все товары, сделать перекрестную таблицу. «Свести товары» — это самое сложное, тут надо как автор, через регулярные выражения и т.п. А далее по кодам работать ежедневно прайсы обновлять. Выделять новые строки, или исчезнувшие позиции. Ну если кто нибудь поменяет коды — по последнему разобранному прайсы от этой организации по наименованиям вычистить новые коды.

Ну и выбрать позиции уже составит не 30 минут, а ровно столько, сколько потребуется времени распознать позиции в заявке. Критерии выборки от количества и т.п. устанавливаем (например сверла от 100шт берем в Фирма1, а от 10000шт в Фирма2). В эту же секунду всё будет в лучшем виде!

Т.е. гугля бы в помощь не привлекал, сервер БД самый верный помощник. Высвободившихся людей вы посадил на периодическую выверку соответствия. Это не сложно, когда удобная отображалка.
По хорошему, надо весь завод датчиками и камерами оснастить, и в БД смотреть где-что делается. А отдел продаж продаж автоматизировать по максимуму, а не в Excel макросы писать.
Про БД и смотреть где-что делается, подумываю написать статью, как реализовал это у нас через qr коды и веб-приложение у каждого рабочего. Рабочий сканирует код — в Google Spreadsheets появляется запись с его операцией, временем, и трудоемкостью. В итоге каждый рабочий видит свою статистику за месяц в режиме реального времени, а мы в свою очередь видим что где делается, и все довольны. Но вдруг снова примитив
Я так в 90-х автоматизировал работу отдела корреспондентских отношений в банке, в котором работал аккаунт-менеджером — парсил макросами файлы с платежными поручениями, вгонял в эксел, в базу Oracle и распечатывал мемориальные ордера. В результате работа дня выполнялась минут за 30. Начальник, увидев, попросил поставить макрос и девченкам.

Потом меня взяли в IT-отдел, научили C/C++ и я уже стал писать для операционистов зала.

А потом я по интернету и телефону нашел контракт и свалил в США C++ программистом по рабочей визе, было это 18 лет назад…

Добрый день. Мой товарищ (на Хабре не зарегистрирован) работает над схожей проблемой и хотел бы обсудить с Вами идеи реализации. Вы могли бы связаться с ним по скайпу (happy_romko) или по почте (reserved4shainsky@yandex.ru)?

По моему опыту, автоматизировать, то есть, как минимум, уменьшить затрачиваемое время на какую-любо операцию можно в 99% российских организациях. И таких операций целый состав и две тележки. И не для всех операций нужно покупать ERP, 1С, документооборот. Для многих вещей хватает любого офисного программного обеспечения и встроенной в него возможности написания скриптов. Что автор и продемонстрировал.
Вспомнил ещё об одном отрицательном моменте рационализации снизу. В смысле когда один работник начинает делать все быстро и хорошо по своей инициативе без общего преобразования системы. Через месяц все привыкают к хорошему но в своей работе ничего не меняют. В результате если раньше заявка конкретно на сверла поступала за три дня до часа Х то теперь будет поступать за 30 минут до часа Х. Просто по всей цепочки до и после исполнителя работники расслабятся. А потом ещё потребуют всю информацию от исполнителя на дискете плюс распечатки. И в случае опечатки отыграются что вот они эти компьютеры.
Дело не в системе или процессе, а в общем незрелом бизнесе и его винтиках. Когда вместо того чтобы достичь общей цели — постротить камаз и продать его за деньги — люди придираются к опечаткам и смазанным печатям
Интересный вариант решения конечно на гугл-таблицах. О таких технологиях мы в свое время даже не задумывались.

Вижу также огромное количество комментов, где тоже перечисляются вполне интересные варианты решения. И это говорит о том, что проблема продолжает существовать и однозначного решения нет. Причем в каждой нише есть свои нюансы.
Мы неоднократно подходили к решению данной проблемы. В основном, как настройка бизнес-процессов для наших клиентов на Интернет-магазины. Одно из них в 1С — конфигурация, которая натягивается на УТ и является надстройкой. Там полноценный обработчик прайсов, товары могут называться совершеннно по-разному, но все сводится в 1 номенклатуру. Цены в разных валютах. Рекомендуемая цена от некоторых жирных поставщиков и т.д.
Суть в том, что для заказа у нас сразу видны все данные по каждому товару. То есть цены и остатки по каждому поставщику, а также предлагаемый системой оптимальный поставщик. Некоторые наши клиенты обрабатывают по 100 разных поставщиков.
Другое наше решение специализировано под биржу товаров шинно-дисковой тематики. Несколько сотен поставщиков регулярно присылают свои прайсы на емайл. Все участники проекта получают полный ассортимент товаров от других поставщиков. Для каждого участника сразу же вычисляется и розничная цена по настроенным для него правилам.
Смысл написанного мною текста в том, что наши оба решения это довольно емкие проекты, которые разрабатывались длительное время и не одним специалистом.

Так что респект автору за оригинальное и относительно простое решение. Перспектив для него на этом рынке предостаточно.
Я как то сталкивался с тем чтобы создать свою базу данных. Есть конечно Microsoft Access, но так же натолкнулся на такой вариант — My Visual DataBase.

Еще можно поискать программки типа ukrsklad.com заточенные на локальный рынок. Сидит программист годами и выполняет хотелки клиентов. Клиенты работают и довольны.
То есть по сути зачем вам изобретать велосипед, когда сотни предприятий работают по схожим с вами сценариям.

Тоже занимался ускорением работы. Смотрю секретарша вручную вносит в базу данных с распечатки звонки. Начал выяснять и оказывается она распечатывает EXCEL файл и ручками всё вносит. В общем пол дня помозговал, один раз сбегал к бухгалтерам, которые в EXCEL профи и вся её работа начала делаться за пять минут, вместо нескольких дней тупого набора.
«Награду» за это я получил мгновенно. Стал делать её работу. Пять минут в месяц, но всё равно обидно.

Отлично когда человек смог решить проблему в поставленных рамках. Большинство комментариев тут выглядят как комментарии на форумах по программированию, когда человек спрашивает "как такое сделать на таком то языке", а в ответ получает "лучше возьми вот этот язык он круче и лучше и быстро сделай".

Молодец! + в том, что это то решение — то что нужно здесь и сейчас, и его можно сделать таким как надо завтра. В ERP вы быстро упретесь в ограничения то сверху то снизу, а то вообще в фундаментальные.
Sign up to leave a comment.

Articles