Если же вы испытали, или сейчас испытываете боль планирования в 1С, то давайте поболеем вместе, и попробуем выздороветь.
Статья написана, в основном, про УПП. Часть проблем удалось снять в ERP (заодно добавив новых), но боль осталась и по сей день.
Итак, поехали.
Обеспеченность
Первое и главное – как узнать, какие потребности обеспечены, а какие нет? Вот есть у меня заказы покупателей, или план продаж, или внутренние заказы, или заказы на производство – это мои потребности (точнее, покупателей). Есть запасы на складах, есть заказы поставщикам (закупка и переработка), есть планы закупок в конце концов – это мои ресурсы. Как ответить на вопрос – какие потребности удовлетворены, а какие нет? Ну и сразу сопутствующий вопрос – а чего не хватает? Что надо купить или произвести?
Простого ответа на этот вопрос нет в конфигурациях 1С. Хотя задача, на первый взгляд, тривиальная – возьми все ресурсы, распредели по потребностям, и будет тебе счастье. Вроде должен несложный отчет помочь, но его нет.
Я, как наверняка и вы, такой отчет делал. Для грубого ответа на поставленный вопрос отчет вполне сгодится, но кому нужен грубый ответ? У людей же бизнес, от ответа на вопрос зависит расход денег, неликвиды, кассовые разрывы, отношения с покупателями.
В попытках уточнить ответ мой отчет стал обрастать условиями и оговорками. Например, этот контрагент – ключевой, ему надо отдать запасы на складе в первую очередь. Но ему нет смысла брать запасы вот с этого склада – это другой конец страны, только самолетом можно довезти, и только в экстренном случае. Или вот этот склад – только для подразделения Х, но в случае особой надобности, приказом директора, с этого склада могут чего-то взять ребята из подразделения Y. Но они должны оформить внутренний заказ, который будет исполнен перемещением.
Возможностей схемы компоновки и языка запросов уже не хватает, чтобы описать все условия расчета обеспеченности, и появляются настроечные справочники. Отчет все больше начинает походить на страшного монстра, а тут еще постоянно обнаруживаются все новые проблемы с качеством данных.
Потом происходит очередной кошмар – меняется бизнес-процесс, заодно и штатная структура, подразделения перемешиваются, складов становится вдвое больше, появляются планы производства, придумывается новый документ типа «Заявка покупателя», который предшествует заказу покупателя и т.д. Короче, причин для смерти Отчета становится столько, что он перестает сопротивляться.
Помощник планирования
Часть вопросов расчета обеспеченности в УПП решает «Помощник планирования». Я раньше очень любил этот инструмент, в него заложены классные идеи и подходы. Но, увы, он так и остался прототипом для решения реальных задач бизнеса. Долго рассказывать по дедушку-помощника не буду, при желании вы без труда найдете массу информации про его ограничения (бутылочное горлышко, например).
Применительно к расчету обеспеченности главный недостаток «Помощника планирования» — необходимость им постоянно пользоваться. Реальная картина обеспеченности меняется каждую минуту, или каждый час хотя бы, а помощник рассчитан на относительно нечастое использование.
Второй важный недостаток – помощник вообще не дает ответа на вопрос «за счет чего обеспечено?». Он только выдает, чего не хватает, т.е. отвечает на сопутствующий вопрос, пропуская главный.
Резервирование и размещение
В определенный момент я обратил внимание на резервирование (на складах) и размещение (в заказах поставщикам и внутренних заказах). Вот оно, казалось бы, то что мне и надо! Резервирование дает однозначный ответ на главный вопрос – за счет чего обеспечена потребность. Там прям написано – железяку с этого склада возьми и иди с миром, а деревяшка приедет через неделю от поставщика по заказу № 23123.
Но иллюзия разбилась о реальность. Резервирование происходит в момент проведения документа (заказа покупателя, например), а место резерва (склад или заказ поставщику) хранится в нем же. Ошибся человек три дня назад – все, трехдневная цепочка резервирования летит к черту. Отменили проведение заказа поставщику двухнедельной давности – получай минусы в регистре резервов. Забрали со склада без резерва, или списали недостачу – все от печки начинать.
Мелькнула надежда в виде документа «Резервирование товаров» — он ведь позволяет за один присест провести корректировку всех резервов. Освободить, перенести, занять более актуальные ресурсы – т.е. нивелирует все недостатки, описанные выше
Надежда продержалась долго, даже переросла в несколько проектов. Я, а наверняка и вы, делали такие штуковины, типа автопересчета резервов или большого АРМ по управлению резервами, чтобы Большой Диспетчер мог перекидывать резервы туда-сюда, снимать и ставить, учитывая потребности и все изменения реальной жизни. Манипуляции этого человека легко укладываются в документ «Резервирование товаров», с точки зрения программиста он просто прекрасен – почти прямая запись в регистры идет.
Но и тут не все гладко. Проблемы с последовательностью остались на месте, т.к. изменение документа потребности или резерва задним числом точно также может увести регистр резервов в минус. Большой Диспетчер уже не может полагаться на данные, которые постоянно меняются. Он только что распределил резервы, через минуту заходит в свой АРМ, и видит, что раздал несуществующие ресурсы (а по наивности еще и позвонил людям и чего-то наобещал).
Плюс тот же недостаток, что и в помощнике планирования – резервированием, в т.ч. АРМом, нужно постоянно пользоваться. Заходить в него, следить за ним, чего-то нажимать. Большой Диспетчер, опять же, нужен.
Самое поганое, что резервирование, как таковое, мне не было нужно. Я просто хотел узнать, что у меня обеспечено, чем оно обеспечено, а чего мне не хватает. А резервирование – это «мое, не трогать!», т.е. целый бизнес-процесс. Который, к тому же, на производственных предприятиях любят нарушать ребята на складе (где нет крутых WMS-систем). Был такой один, душой болел за производство, и при поступлении дефицитных деталей просто прятал их в уголок, «чтобы треклятые продавцы не забрали». Какое уж тут резервирование.
Я, как наверное и вы, пытался создать систему автоматического резервирования и размещения. Вроде задача несложная, больше техническая, на партионный учет похожа. Надо взять все партии резервов и распределить между теми, кто нуждается. Но трудности рождались те же, что и в партионном учете – необходимость восстановления последовательности, сложные алгоритмы, критичность к изменениям бизнес-процессов и схем учета.
А ведь я просто хочу узнать, что у меня обеспечено, чем обеспечено, и что надо купить.
Аналоги
Тема настолько избитая, что уже наверное и не поднимается на конференциях. Годы идут, воз с места не движется.
Везде, где я работал с планированием, нужно было учитывать аналоги.
Самый простой вариант – обычная взаимозаменяемость деталей. В мехобработке, например, распространенный случай – совершенно одинаковые на вид железяки, но выполненные по разным версиям конструкторской документации. Например, из разных марок стали. Или одна – из поковки, а другая – из штамповки. Или одна – собственного изготовления, другая – покупная. Или шероховатость разная из-за разных способов обработки у поставщиков.
Указать взаимозаменяемость таких деталей можно и в УПП, и в ERP. Где-то эта информация даже учтется – например, при подборе материалов в отчет производства за смену. А я хочу при планировании и расчете обеспеченности, чтобы не покупать деталь, аналог которой у меня уже есть на складе.
В реальной жизни учет аналогов, конечно, сложнее.
Например, заменяемость может зависеть от клиента – одному подходит разная сталь, другому кровь из носу надо 40Х. Одному подходит сделанная в Китае, другой – патриот.
Но и это все – простые случаи, когда аналоги связаны один к одному.
Бывает и сложнее. Например, когда делают упаковку полимерную, берут пленку подходящей ширины. Если клиент заказал рулон упаковки шириной 1000 мм, мы берем ширину 1100 мм, срезаем по краям по 50 мм (чтоб ровненько было), и все счастливы. Но сложилась ситуация, когда у нас нет пленки шириной 1100, а есть 1105 мм. Мы, конечно, не паримся и берем ее – просто отходов будет чуть больше. А можем взять 1110 мм, можем 1115 мм, можем даже 1300 взять, если горящий заказ и клиент из любимых.
Получается сложносочиненная формула расчета аналога. Каждая пленка – отдельная номенклатура, т.е. сочетаний для каждой пленки будут десятки. Но применимость сочетаний аналогов зависит от контекста – ширины изделия, которую нам надо получить. Добавим сюда, что пленки одной ширины бывают разными по своим свойствам, но могут заменять друг друга при определенных условиях. А еще рулон шириной 1000 мм можно разрезать пополам, чтобы выполнить заказ, где требуется ширина 450 мм. А еще его на три части можно порезать, и не обязательно одинаковые.
Короче, ад адский. А хочется, чтобы это как-то учитывалось, и ответ на вопрос «обеспечены мы или нет?» система дала.
Вы, наверняка, знаете еще более хитровыдуманные схемы замены материалов. Рассказывайте, не стесняйтесь. Все равно никто нам учет аналогов не планирует автоматизировать.
Гибкость
Точнее, не гибкость, а ее отсутствие. Я, наверное как и вы, много раз слышал фразу – надо не 1С подстраивать под свои процессы, а свои процессы под 1С. Когда работал во франче, сам любил этот лозунг повторять клиентам.
Гибкости в планировании и расчете обеспеченности в 1С нет. Гибкость – это когда ты можешь, без адского программирования, выбрать наиболее подходящий инструмент, немного его поднастроить и получить требуемую схему планирования.
Я к УПП очень хорошо отношусь, но решение для планирования выбирать-то в ней особо не из чего. Это даже не гибкость, а Великое Ничто, вакуум, поле чистое. Можно же утверждать, что Ничто – гибкое? Конечно. В этом и прелесть УПП, за это его и люблю, особенно в части планирования – делай что хочешь, хуже не будет.
Например, приделать к УПП закуп по методу ББВ (барабан-буфер-веревка) – задача несложная, даже обычным программированием, безо всяких там универсальных инструментов. И ничего в системе испортить невозможно своими доработками, т.к. работа-то в Великом Ничто делается. Это как ядерную бомбу на полпути от Марса до Венеры взорвать – солнечная система ничего не заметит.
В ERP уже есть из чего выбирать – четыре способа обеспечения потребностей есть. Но ERP, как говорят ее разработчики на конференции партнеров – система, ориентированная на процессы, и написанная под процессы. Менять способы обеспечения в ERP – взрывать ту же ядерную бомбу, только уже на Земле. Особенно с учетом постоянных изменений от редакции к редакции.
Тем не менее, начинание полезное, есть из чего выбрать. Я пообщался с разработчиками, задал им вопросы о своей боли, получил неутешительные ответы – боль этой таблеткой не лечится. Отчета по обеспеченности нет, аналогов нет, добавлять или изменять способы обеспечения – только через конфигуратор, учесть в схемах обеспечения свои объекты метаданных не получится.
Не знаю, как вам, а мне в таком сравнении ближе Великое Ничто.
Свои объекты метаданных
Ну, тут и рассказывать особо нечего. Любой добавленный объект метаданных никак не попадет ни в какую схему планирования или обеспечения.
Примеров самодельных объектов метаданных и я, и вы знаете миллион. Если скрестить УПП с отраслевыми решениями, то самодельные объекты появятся сами собой. Ни один из них в планировании участвовать не будет, и без конфигуратора здесь не обойтись.
Если добавлен не прям объект, а реквизит, например, то еще куда ни шло – он хотя бы в отборе помощника планирования появится.
В контексте самодельных объектов даже хорошо, что в 1С такое планирование. Представьте себе, было бы оно как РАУЗ – цельное, проверенное, работающее, самодостаточное. Многие из нас рисковали жизнью, добавляя вообще совершенно новый документ движения товаров, и включали его во все цепочки РАУЗ? Или добавляли реквизиты в номенклатуру, которые бы влияли на решение СЛАУ? А планирование не такое – ему без разницы, что вы куда добавили, все равно мимо пройдет.
Резюме
Раньше часто слышал фразу о том, что про планирование – уникальный процесс для каждого предприятия, и изготовить типовое решение для всех его вариантов – невозможно.
После этой фразы я полюбил планирование, как класс задач.
С одной стороны, фраза избавляет 1С (и вообще любого разработчика) от необходимости изготавливать типовое решение.
С другой стороны, фраза окрылят внедренца – давай, действуй, на этом поле нет законов, правил, правильных и не правильных решений! Твори!
Я творил несколько лет, наверняка и вы тоже. Что-то получалось, что-то нет, где-то на пути остались монструозные системы планирования и резервирования, дикие отчеты с нечитаемыми настройками и алгоритмы, в которых я теперь сам не могу разобраться.
И все из-за этой фразы. Твори, каждый раз твори, потому что типового решения нет.
Потом только дошло, что фраза неправильная, недосказанная, упущено в ней что-то.
Нет типового решения для клиента. Или по-другому – нет коробочного решения для пользователя. Нет такой программы в мире, в которой пользователь сам себе планирование сделает. Есть программа, где пользователь сам себе бух.учет сделает, все мы ее знаем.
Но не пользователями едиными внедрения богаты, там есть еще и программисты 1С. Пользователь – он же только на кнопки нажимать умеет, да и то ошибается все время. Программист же – и код напишет, и схему компоновки, и схемы хранения данных знает, и метаданные видит, и цель планирования знает, и процессы знает… Понимаете?
Типового решения задачи планирования для пользователя – нет, а для программиста – есть. Должно быть типовое решение задачи планирования для программиста. Инструмент,
- обладающий определенным уровнем абстракции (но не как конфигуратор, разумеется);
- решающий базовые алгоритмы задач планирования, чтобы не париться о них на каждом внедрении;
- умеющий использовать все необходимые данные системы для целей планирования;
- который для настройки не требует программирования, но и не скатывается в вульгарный эникей.
В общем, нужен инструмент, созданный программистами для программистов.
Ближайшая понятная аналогия – Конвертация данных. Не сильно простой, но и не сложный инструмент, решающий конкретную, понятную область задач – обмен данными – и содержащий все необходимые функции для успешного решения этой задачи.
Конвертация почти полностью удовлетворяет критериям, которые я предъявил системе планирования:
- обладает определенным уровнем абстракции (ничего не знает о метаданных, умеет работать с разными платформами, умеет переносить все или по кускам и т.д.);
- решает базовые алгоритмы задач переноса данных, чтобы не париться о них на каждом внедрении;
- умеет использовать все необходимые данные системы для целей переноса;
- для настройки не требует программирования*, но и не скатывается в вульгарный эникей.
* — вот только тут неправда, программировать в конвертации обычно приходится. Но есть и масса примеров, когда не приходится.
С моей точки зрения, и в контексте статьи, Конвертация данных – практически идеальный пример типового решения для программиста. Конвертация даже не пытается делать вид, что она для пользователя, поэтому ей не приходится таскать за собой юзабилити, процессный подход, удобные настройки, требовать особой организации данных и прочего балласта решений для пользователя.
Еще стоит упомянуть Бюджетирование в УПП. Это система, позволяющая собрать любые данные из системы с помощью запросов, и построить из них бюджетное планирование. Прямо из коробки обычно не работает, но если посадить программиста за настройку, то позитивный результат можно получить достаточно быстро.
Вдогонку упомяну инструмент, который лично мне показался правильным – Монитор ERP. Цель инструмента многогранна, но в то же время очень проста – дать информацию о бизнесе в правильном виде. Главное – в мониторе ERP можно писать схемы компоновки, определять свои показатели, правила их расчета и контроля. Разумеется, этого не сделает пользователь, хотя попытка сделать интерфейс настройки для пользователя предпринята – есть предопределенные показатели, стратегии, цели. Посади программиста с правильной постановкой задачи – он сделает шикарную систему контроллинга для предприятия.
Теперь, собственно, главный вопрос: а где инструмент для настройки планирования и расчета обеспеченности, похожий по своей гибкости и возможностям на конвертацию данных, бюджетирование, и монитор ERP?
Типовые конфигурации 1С – они, вроде, для «учета и управления». Основа управления – план и контроллинг. Контроллинг худо-бедно построить можно. Построить правильное, современное планирование, умеющее быстро реагировать на изменение среды, учитывающее особенности российского подхода к учету, – практически невозможно.
Оттого и крен во фразе «учет и управление» на первое слово. А хочется, чтобы был баланс, одно ведь из другого следует.
Все изложенное является личным мнением автора, разумеется.
P.S. Ну и от себя спрошу, очень интересно, может знаете – а кто принимал решения, как инструмент в УПП или ERP делать правильным, а какой – неправильным? Почему бюджетирование – правильное, а планирование – неправильное.
Комментарии (40)
rpiontik
09.04.2019 07:55+1Проблема 1С внедренца в комплексе «Бога». Отчетом нельзя побороть бардак, как и конфигурацией. 1С неспроста «под себя строит». Она не строит, а дает бардаку общее направление. Все ваши проблемы от отсутствия четкого бизнес-процесса в самой компании. Если бы он был — его просто нужно было бы автоматизировать.
Но проблема в том, что самим внедренцам и франчам это не нужно тоже. Чем больше итераций по доработке отчета, тем лучше. Богаче.
И 1С это не нужно. Т.к. чем франчи богаче, тем и 1С тоже. Потому, что продвигается франчами. Потому, что имеет неавтоматизированные зоны, на которых можно кормиться.
Т.ч. бардак — это альфа и омега 1С. И нечего жаловаться на судьбу;)
Novaplus
09.04.2019 07:59Да, это боль ещё какая. Каждый бизнес бьется об стенку и пишет кучу программ под себя. У нас например уже скоро будет более 10 разных приложений, которые написал программист и каждое приложение точнее интерфейс решает 1 или несколько задач для бизнеса, это адски не удобно. Хочется универсальную программу. Тот же Битрикс24 познакомившись вроде супер, а когда детали начинаешь программировать и так сказать пилить напильником под себя, то выходит много разных косяков, которые не может решить эта crm. Благо в нашем бизнесе нет склада — я представляю какой это геморрой. Ничего не остается делать, как только пилить напильником под себя затачивать, при этом тратить время, а после написанной программы ещё исправлять небольшие правки и доработки, которые ты сразу не заметил, когда только в голове это все было. Сейчас время в бизнесе наступило такое, что много ПО, необходимы ит специалисты, а их нет или денег у компании нет, чтобы их купить вот и приходиться на своих костылях допиливать, подпиливать ПО и сидеть на этом не удобном программном продукте. Бель ещё та… я уже на хочу писать о том, что тебя как айтишника не понимает директорат и те люди, которые платят. Айтишник должен видеть будущее и настоящее компании и внедрять в компании продукты такие, чтобы быть на уровне, а если этого не будет то бизнес со временем помрет.
epishman
09.04.2019 08:10-1Проблема методологическая, есть как минимум 2 подхода.
1) Построение точного графа сопоставлений планируемых расходов с планируемыми приходами через цепочку спланированных резервов и спланированных перемещений. Если кто-то через 3 дня снял свою потребность — неибет, все равно ему всучат эту деталь, и заставят писать объяснительную почему он ее не потребил. И никакого заднего числа. Алгоритм предполагает создание промежуточной структуры данных — того самого графа, и одним отчетом тут не выкрутиться.
2) Укрупненное планирование, когда создются виртуальные склады планирования (группа территориально близких, где можно перебросить в течение дня), потребности агрегируются по этим виртуальным складам, также могут создаваться укрупненные закупочные склады (по территории и функциональной ответственности). Теоретически правильно создавать также виртуальные номенклатуры (по сути группы аналогов). Получаем параллельный контур виртуальных складских проводок, и это тоже не отчет. В этом случае коррекции потребностей / закупок не так жестко влияют на процесс, по сути буферизуясь на виртуальных складах.
PS
И это все не про стандартную 1С
gennayo
09.04.2019 08:16+1Основная боль в том, что практически каждое предприятие под термином «планирование» подразумевает что-то своё. Отсюда и неудачные универсальные решения от вендора, и обилие велосипедов и костылей.
Cassiopeya
09.04.2019 08:43+2«Что ж вы так убиваетесь, вы ж так не убьетесь!» (С)
Серьезно, может стоит уже как-то иначе озаглавливать статьи про 1С? Каким бы ни было отношение к нему, но это решение есть реалии очень многих российских производственных и не только производственных компаний. Ничего, работают люди, программируют. Не самоубились еще, хвала богам.
nmivan Автор
09.04.2019 08:47вы это пацанам хабровским скажите.
rpiontik
09.04.2019 09:05+1Зачем? Нелюбовь хабра к 1С, в целом правильная. По своей природе. Но не по структуре. Т.е. он ее не любит, чаще всего — потому, что. Но 1С действительно поднимает вопросы не ИТ индустрии, а финансиста и бухгалтера. Причем тут в неком извращенном виде. А это, скажем так, не сильно интересные и популярные темы. Поэтому, 1Ссовцы тусуются «отдельно».
Хочу подчеркнуть, что я с 1С провел около 10 лет своей жизни. Сделал несколько конфигураций с нуля (крупных и сложных), которые работают до сих пор. Инструмент для своих задач — отличный. Маркетинг его — гениальный. Но, повторюсь, перечень этих задач ограничен. Поэтому и понимание вы найдете на хабре ограниченное.Ta_Da
09.04.2019 13:321С это ведь не только финансисты и бухгалтера, это еще и логисты, например. И множетсво задач по интеграции 1С с чем-либо еще, и распределенные базы, и вопросы архитектуры решений (пусть и с учетом ограничений платформы).
При этом, на хабре есть один очень популярный автор, который пишет про выкладку товаров на полке, зубров, пчел и практически ничего не пишет про IT, однако собирает множество плюсов в карму. А вот интересные статьи по 1С (которые вполне могли бы быть интересны сообществу хабра) в итоге публикуются на других площадках, потому что тут они получат только комментарии про «ахаха КонецЕсли» (это они еще директиву "#Вставить и #КонецВставить" не видели).
Может есть все-таки еще причины «тусования отдельно», кроме ограниченного перечня задач?
Neikist
09.04.2019 13:47Все таки обычно претензии не к русскому языку, а к дикой ограниченности языка.
Ta_Da
09.04.2019 17:34Не так. Это у вас претензия к «отсутствию лямбд» и т.п. в каждой статье, где упоминается 1С, заодно плодите миф о том, что «1С это только про бухгалтерию и интересных задач нет».
Вот когда вы мне покажете, как к статье о языке C люди будут писать комментарии на тему «да как можно этим пользоваться, я вот 3 года на C писал, но там нет лямбд — язык ограничен», тогда я ваш аргумент приму.Neikist
09.04.2019 17:36Тащемта мне и C дико не нравится в отличие от плюсов из за своей ограниченности, но там хоть доступ к памяти есть и возможность ссылки на функции передавать. И нет, я не пишу что 1с про бухгалтерию только, за 4 с копейками года с ней ни разу не столкнулся, но 1с про учет.
Ta_Da
09.04.2019 17:48«1С про учет», это тоже самое что «javascript про интернет-магазины».
Neikist
09.04.2019 17:50Покажите пример не учетных систем на 1с. Желательно чтобы это массово было и выбор более чем из 10 работодателей на всю страну, но интересны любые варианты. И да, js это, имхо, веб. А на бек или в мобилки его суют извращенцы.
Ta_Da
09.04.2019 18:031) Для того чтобы приводить примеры, давайте определимся, что вы понимаете под «учетная система» и «не учетная система»?
2) Вы различаете «веб» и «интернет-магазины»?
3) Если выбор менее 10 работодателей на всю страну не считается примером, будем исключать из «разнообразие задач на других языках» операционные системы и социальные сети, например?Neikist
09.04.2019 18:081) 1С заточена только под b2b, и все решения что я знаю заняты в основном тем что хранят информацию о событиях на предприятиях (ремонты, добыча, расходы, клиенты и еще сотни подобного) а потом эту информацию как то обрабатывают.
2) Да. Но js место только в веб фронтенде. Тоже довольно узкая ниша, хоть и чуть более широкая чем у 1с (но без бека это бесполезно).
3) Я бы исключал, хоть разных социалочек и подобного заметно больше 10 (особенно если всякие «стартапы» считать).
Дополню еще к пункту 1 — чаще всего информация напрямую касается расходов и доходов.rpiontik
09.04.2019 22:10Ой, ой :) Главное, чтобы ваши рассуждения о JS никто из js-совцев не увидел ;) На js есть вполне себе серверные решения, например NodeJS. И куча игр, кстати. И WEB к js имеет посредственное отношение. Js в WEB представлен из-за очень крутой кросплатформенности, что позволяет ему работать на разных браузерах и ОС. Я даже больше скажу, на микроконтроллерах тоже работает js. Т.ч…
Neikist
09.04.2019 22:13То что оно есть это факт конечно, но я считаю это ошибкой. Хуже js придумать что то сложно, имхо. Но да, если кто из jsников это увидит — карму могут подслить.
rpiontik
10.04.2019 07:07Ну вы ошибаетесь насчет js. Я без фанатизма скажу. Язык действительно эффективный. Я с ним давно знаком. Кстати, когда-то использовал ActiveX в 1C с его интерпритацией для обсчета графов. Можно было бы таскать подключенную библиотеку, но это сильно усложняло поддержку. А js код хранился в 1С и можно было его "мутировать" в любой момент. Делалось, к слову, для логиста. Плюс к этому, код разливался по рбд на склады и не требовал админских прав для обновления конфигурации. Но самое смешное, он экспортировался в html страницу и работал независимо доя маркетологов.
Вот такая дружба была 1С и js. А вы его не любите:))Neikist
10.04.2019 07:53Да там ужас на ужасе и ужасом погоняет. В основном раздражает динамическая слабая типизация + наслоения гор легаси в языке. Еще подбешивает npm. А именно что leftpad и подобное не просто живет, но активно используется. Ну и любовь jsников запихивать свой любимый язык куда ни попадя.
rpiontik
10.04.2019 12:28запихивать свой любимый язык куда ни попадя.
Тонко ;) Но… я попробую реабилитироваться ;)))
Дело в том, что у каждого склада был свой алгоритм расчета маршрута, которыми управлял главный логист. А код в систему вносился документом и проводился. Т.е. алгоритм расчета был версионирован, кастомизирован и встроен в workflow процессов. Т.ч. решением этой частной задачи я горжусь до сих пор. Уж сколько лет прошло.
Я конечно мог ее сделать на VB… но вот назло не стал :)))
ChePurator
10.04.2019 06:20Когда я в детстве проходил мимо ракетостроительного кружка (я тогда занимался в авиамодельном) услышал одну фразу от тамошнего руководителя: «Если буду мощные движки, то и швабра в космос полетит»
Иными словами — если есть мощные движки (энтузиазм и/или деньги), то и на 1С можно аля фотошоп написать! Скорость и качество работы этого 1Сшопа — это, как говорится, вопрос второй!
Но 1С — это в первую очередь СУБД.
Одна из основных целей БД — фиксация информации в различных разрезах для ее последующего анализа. (Более академичное определение с википедии: База данных — совокупность данных, хранимых в соответствии со схемой данных, манипулирование которыми выполняют в соответствии с правилами средств моделирования данных)
Вот и получается, что многие БД, и 1С в том числе, делаются для решения именно учетных задач. Что и как учитывается — зависит от конкретного случая.
За 11 лет, что я работаю с 1С, я для себя понял такую штуку: 1С это очень хорошая система прототипирования. Для начинающего, мелкого или среднего бизнеса — сойдет. Для крупного — только в отдельных сегментах (типа той же бухгалтерии).
1С — этот комбайн, в который пытаются запихнуть много разных технологий: FTP-клиент — свой, HTTP-клиент — свой, SMTP-клиент — свой, почтовых клиентов — два минимум (просто почта и интернет-почта), работа с файловой системой — своя, и т.д. Цель этого — универсальность и кроссплатформенность. Последствия — ограниченность и/или убогость реализации. Цена — боль от скрещивания ежиков с ужиками в ситуациях, когда нужно немного НЕ так/немного НЕ то.
Т.е. для достаточно простого и ненагруженного решения — самое то. Ибо из всех возможностей платформы используются не более 10-15%.
Но если говорить вообще, то у 1С проблем гораздо больше. И они гораздо серьезнее этих вечных холиваров про программирование на русском языке.
(В конце концов — никто не мешает написать транспайлер, который позволит писать по-русски и на C/C++! И что? Все будут плеваться на C/C++?)
1С — это давно уже не только/не столько платформа: платформа является продуктом маркетинговой политики фирмы 1С. И говорить об 1С и ее плюсах/минусах надо именно как о таком симбиозеежика и ужика
Nikita001
09.04.2019 16:53O100 sub
O102 if [#2 GT 5] (if parameter #2 is greater than 5 set F100)
F100
O102 elseif [#2 LT 2] (else if parameter #2 less than 2 set F200)
F20
O102 else (parameter #2 between 2 and 5)
F200
O102 endif
O100 endsub
Вот те пожалуйста, КонецЕсли, КонецФункции — а ведь это совсем не 1С.
И на этом программируют в 2019, никто не жалуется.
Я думаю, иррациональный снобизм программистов по отношению к 1С связан с тем, что они долго учились (читали Тору), а вероломная фирма 1С дала лапотным бухгалтерам доступ к коду.
И ладно бы к коду SAP или Axapta, где те бы все равно ничего не поняли, поскольку и синтаксис на английском + километры бойлерплейта, и переменные переводят в Promt с русского на английский, в результате чего коллега за соседним столом будет полдня голову ломать.
А тут на тебе, все по русски, и даже можно понять, о чем там, заглянув через плечо. Магия профессии умерла.
Мало этого, 1С еще и дала простолюдинам конструктор запросов, где можно не написав строчки кода слепить SQL любой сложности и вложенности. Говорят, когда вышла первая конфа с ней, некоторые ее специально отключали, боялись что у них работы не будет.
Кстати говоря, даже в 1С можно надуть щеки, и как #НастоящийПрограммист писать EndIf, EndFunction. Ведь набирая текст в латинской раскладке, мы чувствуем себя причастными к Великой Англосаксонской Высокотехнологической Цивилизации произведшей на свет Айфон и Теслу, а это очень важно.
А так, можно, наверное, попробовать кодить и на китайском, если такое уж отвращение к родному языку, и по-моему, в 1С и такую опцию синтаксиса сделали.Ta_Da
09.04.2019 17:58Исходя из моего опыта, основная проблема в том, что как среднестатистический 1С-ник ничего не знает про, допустим, шаблоны проектирования, так и среднестатистический не-1Сник ничего не знает про 1С. И те и другие узнавать причем не стремятся =)
Т.к. знаний нет, они заменяются набором мемчиков и шуточек.
Примеры из личного опыта. Решил я получить наконец диплом. Столкнулся в процессе с двумя характерными ситуациями:
1) одногруппники it-шники, с иронией относятся к разработке на 1С, при этом многие про 1С слышали только на хабре/лурке. Когда начинаешь им показывать платформу, показывать решения, приводить аналогии из мира .net|Java, сильно удивляются.
2) преподаватели в вузе вообще выдали мне сумасшедший набор мифов и мемов
«в 1С запрещено изменять код, если поменяешь — посадят», «в 1С не пишется код, там только галочки расставить можно», «1С это бухгалтерская программа, как вы собираетесь на ней что-то еще делать?», «программирование в 1С? вы бы еще сказали что программируете в PowerPoint» и т.д… В отличие от более молодых студентов, попытки что-то показать и объяснить наткнулись на пустой взгляд и повторение тех же мемов. Плюнул и писал на Java.fukkit
09.04.2019 21:27в 1С запрещено изменять код, если поменяешь — посадят
Слишком хорошо, чтобы быть правдой.
С удовольствием посадил бы куда понадежнее одного чудо-франча, снявшего с поддержки спецконфу и накостылившего всякой хрени прям внутри стандартных форм.
Пытаюсь объяснить заказчикам, что иногда бывает один раз дешево, потом всю жизнь сердито. Но нет. К некоторым понимание приходит исключительно через собственный негативный опыт.
Nikita001
09.04.2019 21:41А вот с формами фирма 1С реально через одно место все сделала.
Были бы эти элементы на формах тупо описаловом через Xml или Json, изменения элементарно мержились бы в GIT.
Поэтому, понимаешь ли, надо в коде создавать элементы управления, чтобы можно было обновлять.
Да на кой тогда нужен визуальный редактор с таким гемором?
Мне проще в Java в Eclipse Windows Builder работать со Swing, раз это все что вы можете предложить!
Это даже если забыть что первая версия визуального редактора управляемых форм была настолько глючным уе№;%: ем, что там даже копи-паст не работал…rpiontik
09.04.2019 22:06Надо сказать, что 1С сделала мерджи тогда, когда еще про гит и знать никто не знал. Я про объединение конфигураций. Да сериализация и десериализации тоже. Имею ввиду выгрузка и загрузка данных БД.
Просто все решения в 1С особенные. Инхаусные что-ли.
archimed7592
11.04.2019 18:37Интересно, сколько из этих хабрапацанов получает зарплату, рассчитанную не в 1С, а в их собственном ПО :)
paranoya_prod
09.04.2019 10:18Если разница в аналогах неважна, то заводим все как «Товар Б». Склад все аналоги перемаркировывает под «Товар Б». Если разница в аналогах важна, то это уже не аналоги, это разные товары.
В бытность свою работы в компьютерно-сервисном магазине заправляли картриджи и струйные и лазерные. Закупали объёмные тубы для заправки, как для продажи, так и для заправки. Чтобы понять сколько чего нужно, пришлось делать документы, которые одну литровую (килограммовую) тубу списывали со склада продаж и оприходовали несколько материалов для «заправок» на сервисный склад. Соответственно, при подготовки к закупке смотрелось кол-во проданных туб и кол-во заправок. После чего заказывалось нужное кол-во туб для обоих складов. Основная проблема была административная — следить, чтобы процесс «перевода» всегда осуществлялся. Как только переставал следить, остатки переставали сходиться.
PS. Чем больше я читаю статей, про то, как в 1С приделывают новые отчёты, атрибуты, докумены, потому-что «плёнка не той ширины», тем больше убеждаюсь, что планированием не пахнет нигде и поэтому программисты, как бы они не старались не автоматизировать хаос, всё равно его автоматизируют. И данная статья тому подтверждение.
Какая боль, какая боль, хаос — порядок, 5:0… :)MinimaJack
09.04.2019 13:29Профиль 5 метров вполне себе аналог профилю 2.5 метров с коэффициентом 2. И это разные товары, с разной ценой.
nmivan Автор
09.04.2019 13:32Пленки — это разные товары, кто спорит-то. Но от этого они не перестают быть аналогами.
Просто аналог — понятие относительное, у него есть применимость. Для клиента разные пленки — не аналоги, ему надо упаковку шириной 500 мм. Для производства этой упаковки пленки шириной 500, 600, 1000 мм — еще какие аналоги, потому что можно или разрезать пополам, или кромку срезать.paranoya_prod
09.04.2019 14:56Для клиента разные пленки — не аналоги, ему надо упаковку шириной 500 мм. Для производства этой упаковки пленки шириной 500, 600, 1000 мм — еще какие аналоги, потому что можно или разрезать пополам, или кромку срезать.
И тут мы подходим к правильной организации процесса. Если нужна плёнка 500 мм, а мы закупаем 600 мм, то это не плёнка, а материал и уж на выходе мы получаем продукт «плёнка упаковочная 500 мм.». То есть, нужен документированный процесс преобразования материала 600 мм в плёнку 500 мм. И всё, не нужно никаких доработок в 1С.
Даже в 1С: УТ это можно делать через сборку/разборку комплекта. Продукт «Плёнка 500 мм» поступает на основной склад, а материалы «пленка 600» и «плёнка 1000» поступают на склад цеха переработки. Важно, чтобы для хранения материалов для цеха переработки было отдельное помещение или огороженное/выделенное место, чтобы фактические остатки сходились.nmivan Автор
09.04.2019 15:04Есть процесс преобразования одной пленки в другую. Нет проблем в том, как организовать учет этой операции — преобразования одной пленки в другую.
Задача в том, что объективно нужны пленки всех указанных ширин. Но в какой-то момент времени может сложиться ситуация, что идеально подходящей пленки нет.
Возникает вариативность, и из нее надо выходить с наименьшими потерями.
Набирать пленки про запас тоже нельзя, они портятся от длительного хранения. Срочно заказать тоже нельзя — их делает полтора завода, и требуют план закупа за 1-2 месяца, чтобы составить свою программу.
Ну и все это прекрасно разруливается планированием.
MinimaJack
11.04.2019 09:04Какие процессы, акстись… когда это разовое — не вопрос, но когда массово необходимо обрабатывать сотни заказов — никто не будет страдать с организацией склада, учета трудозатрат на порезку и прочим.
Пример аналога на пальцах — Оперативная память:
Есть различные марки(параметры одинаковые):
- Kingston
- Crucial
- Hynix
Все взаимозаменяемы, все аналоги.
Но нельзя их смешать в одну кучу, один заказчик сказал что ему надо только Hynix, другому все равно, третьему не надо Kingston. Остатки товара надо видеть по каждой марке, а не в целом по «памяти» и для их закупки.
Приходит запрос на 1000 компов, по спецификации заказа «марка памяти» не важна, в спецификацию суют самую дешманскую… но их на складе 500, без аналогов ждать месяц на поставку и сорванный контракт? Или «Лепить лешего» и делать по документам из
Crucial -> Kingston (аля комплектацией)?
Какая тут организация процесса? Тут чистейшей воды использование аналогов.
p.s. в планирование не верюparanoya_prod
12.04.2019 10:13Договоры на поставку на 1000 компов просто так не лепятся. В них чётко оговаривают сроки поставок, после изучение наличия запчастей на складе, времени на их дозакупку и привоз нехватающих запчастей. Поэтому, в таком договоре, к примеру, отгрузка первой половины заказа на 500 компьютеров будет проведена через месяц (компьютеры ещё собрать надо), вторую половину ещё через месяц, когда недостающие модули памяти уже приедут.
Те, кто так не делает — ССЗБ.
Вот когда у компании мелкосерийное производство, тогда надо думать по-другому и тут вполне могут сработать аналоги, но это не факт. Именные Кингстоны можно отображать в учёте отдельно, а всякая второсортность может вполне идти под названием «Дешманская память 4ГБ», соответственно на складе будет две коробки — одна с Кингтоном, другая с различной «дешманской» памятью.
PS. По моему мнение, когда что-то делалось один раз, то этот процесс стоит задокументировать и внести в тетрадочку «Процессы», в раздел «Одноразовое», чтобы в возможный следующий раз у компании уже было решение, на которое не надо тратить много времени снова. :)
SergeyUstinov
09.04.2019 13:32Про хорошее бюджетирование в УПП — насмешили. :)
А про резервирование — можно сделать. Я делал, правда не для 1С, а для навика. Но и под 1с переделать можно.
Вот здесь почитать можно:
www.sql.ru/forum/1244237/algoritm-rezervirovaniya-dlya-neskolkih-skladov?hl=%f0%e5%e7%e5%f0%e2%e8%f0%ee%e2%e0%ed%e8%e5
Shtucer
Ох. Вспоминая какую боль я преодолевал, вводя в одной конторе этот самый учет… Но не потому что учёт "плохой", а потому что "так было заведено с покон веку". И этап перевоспитания менеджеров растянулся года на два. А привычки были ого-ого. Ради "любимого" клиента подрезать пару позиций из чужого заказа, просто по звонку на склад: -Вась, там ща клиент хороший приедет, ты ему отгрузи пару километров трубы.
-Но у меня всего два км этой трубы!
-Да, я знаю (откуда это знание бралось, для меня было загадкой, потому что в тогдашней программе, кажется, "Парус", ниодной актуальной цифры не существовало!), она в заказе у Пети весит, но я дозакажу, а клиент хороший!
В конце месяца Вася на планёрке отдувался за недостачу, но у него все ходы были записаны на специальной бумажке. Программа, ха! Он всегда знал кому, чего и почему отпустил!
Потом долго мы подгоняли тулуп одинэски под компанию, а компанию укладывали в прокрустово ложе одинэски. Рады были только бухи. Но потом привыкли все, да так, что приноровились торговать чуть ли не с колёс, но не долго, там попёрло ещё такое..., но уже от ума. На любую ERP и прочие программистские причуды найдётся хитрой болт с нарезкой под жажду продать побольше и побыстрее.
archimed7592
Вы так говорите, как будто в том, чтобы «продавать больше и быстрее» есть что-то плохое :)
Shtucer
А вот и нет! Все эти внедрения, это бесконечный процесс. И это не обязательно борьба с продавцами, а как бы погоня за их эффективностью. "Хитрый болт" здесь это положительная оценка: пока ты программируешь бизнес-процессы, хороший управленец уже думает над тем, как их можно оптимизировать.