Pull to refresh
101
0.8
Send message
Я уже говорил, что 1С является полной по тьюрингу, и в принципе — позволяет делать все что угодно. Проблема в том, что это очень сильно нарушает договоренности большинства людей о том, что есть что. Все-таки большинство работающих с 1С людей так или иначе закладываются на некоторое стандартное (принятое в стандартной конфигурации) поведение документов: что непроведенный документ не изменяет регистры учета, что проведение документа атомарно и является видимым моментом изменения свойств объектов в БД, что документ можно распровести, и т.д. Вы можете назвать документом что угодно, и наделить его какими угодно свойствами. Но это не очень практично, по моему мнению.
Еще раз повторюсь — если достаточно упорно натягивать сову на глобус, она натянется! Да, можно объявить каждую операцию документом, и проводить (при интенсивной работе) от единиц до десятков документов в секунду. Но 1С не рассчитана на такое обращение с документами. Да и зачем? Есть специализированная система, которая с потоком событий прекрасно работает. А 1С получает время от времени выжимки из интересующих ее событий уже в виде документов. Для бухучета совершенно неинтересно, из ящика с каким серийным номером была взята конкретная палка колбасы. Им достаточно разреза товаров, максимум — партий. Всякий инструмент хорош для того, для чего он был задуман, как мне кажется…
Вот самое неприятное — это что я понимаю, что вы не понимаете. И даже понимаю почему. И даже знаю что делать. Но в режиме комментариев на хабре поменять установки в вашей голове, скорее всего, не смогу. :-( Нужен лист бумаги и личное общение…

Когда я пишу «у меня» — это значит на одном из складов с колбасой. В реальном мире, да. Стоит мужик, достает батон, сканирует штрих-код, принтер ему печатает этикетку, он ее клеит и кладет в другой ящик. А система WMS в таком же реальном режиме времени мужиком управляет (т.е. говорит что откуда взять, куда положить, и регистрирует что он там делает). У мужика нет документа — он просто берет товар откуда сказала система, обрабатывает его, и кладет куда ему система же показала. Много позже (может быть через 10 минут, а может быть через час) родится документ, в котором будет сказано что он, имярек, перепаковал 56.130 кг докторской колбасы для сети Ашан. А в конце смены, родится еще один документ — по его KPI за смену для расчета зарплаты. Смысл моих много-букв в том, что события в реальной жизни у него происходят «здесь и сейчас», они регистрируются в системе в режиме «он-лайн» (почти сейчас). А документы будут потом (и притом, не на все произошедшие события). Это в корне отличается от бухгалтерского подхода, когда событием признается только то, что нашло свое отражение в каком-то документе.
Нет, пойдем с другой стороны. У меня пользователь производит перемаркировку одного куска продукции из заводского кода в код торговой сети. При этом:
— В исходном ящике уменьшается количество продукции
— В ящике торговой сети увеличивается количество продукции
Уже отличие от документарной модели: состояние объектов в БД изменилось, хотя документ не проводился. Далее:
— Менеджер зоны переупаковки (программный модуль) отмечает убыль продукции в исходном коде (и одновременно, уменьшение потребности в продукции в коде торговой сети). Возможно, он приходит к выводу о необходимости пополнения своей зоны продукцией из хранения.
— При этом срабатывает пересчет резервов, и часть ящиков из хранения расписывается к доставке в зону обработки товара.
— При этом, возможно, обнаруживается возможность перенести часть резервов с одних паллет на другие чтобы максимально быстро освобождать места склада.

То есть на складе в разных зонах случаются разные события в режиме «прямо сейчас», которые запустило одно единственное событие в виде сканирования штрих-кода на товаре.

Другой пример: мужик с терминалом идет и видит, что сверху из дренажа кондиционера капает вода с риском попадания в товар. Он входит в режим перемещения объектов, и переносит поддон с товаром с одного места на другое (естественно, сканируя штрих-коды). И тут тоже нет документа: он просто увидел проблему и переместил товар. Потом, может быть, пойдет к начальнику склада и заблокирует это место до момента устранения течи. При этом все остальные на складе немедленно видят этот товар на новом месте. Тоже нет документа, а состояние объектов склада поменялось.

Разумеется, некоторые события могут оставить след в виде документов. Но в этой идеологии документ — это всего лишь след (причем не буквальный, а агрегированный — например до уровня SKU и партий) фактически произведенных операций. Документ нельзя ни провести, ни распровести, и он вообще не является центральной сущностью. События происходят в on-line и меняют состояние живых объектов в базе. А документы — это обобщенная информация о событиях для экспорта в соседние системы (которые как раз документ-ориентированы).

Я хочу отдельно заметить — все описанные операции можно извратиться, и запихать в документную модель. По типу: а пусть он не просто перемещает товар, а заведет с ТСД документ перемещения, переместит и сразу проведет. Можно придумывать документ, у которого табличная часть может проводиться построчно (инкрементальное проведение документов). В общем, всегда есть пути решения (более или менее кривые) — и разработчики разных не-бухгалтерских систем на базе 1С их успешно находят и реализуют. Но смысла в этом я не вижу. Если процесс хорошо ложится в документную модель — тогда берем 1С и работаем в стандартной конфигурации (плюс внешние обработки и отчеты). Не ложится процесс в документно-бухгалтерскую модель — значит просто делаем его в другой среде, и нечего мозг себе и другим насиловать.
А если заменить документы на события — придется всю идеологию менять. Как минимум проведение документа исчезает. А с ним и распроведение. Ну и в событийно-ориентированной системе как-бы неправильно зависать в событиях по несколько минут. Поэтому придется действия по событиям делить на синхронные и асинхронные… Но в конце-концов непонятно, зачем это. На самом деле, документная модель в 1С прекрасно описывает ее родную предметную область — и есть смысл таковой придерживаться. Лучше делать хороший продукт с четким фокусом, нежели аморфную платформу для автоматизации всего. Я так думаю…
Ну так и на Java она тоже написана… И на SAP она написана… И в комплекте Dynamics она тоже написана! То есть есть из чего выбирать. Дальше можно долго разбираться, где будет больше стоимость разработки, где лучше TCO и все такое прочее…
Ну значит можно считать тьюринг-полноту 1С подтвержденной, и утверждение что на ней можно написать WMS доказанным! Я, однако, не уверен что это стоит делать. То есть что написание такой штуки на платформе 1C имеет преимущества перед связкой Java/Tomcat/Hibernate, например.
Переупаковка и домаркировка для торговых сетей в ней же? Сборка миксов в ящики клиента в ней же? Или это чистый РЦ, где движение идет преимущественно поддонами, и иногда отдельными коробами без вскрытия? Серийный номер на уровне ящика, или только на поддоне?
Ну-у, не соглашусь, вероятно. Имея некоторое отношение к разработке систем управления складами для пищевки, скажу что при необходимости интеграции с весовым оборудованием и сборки одной строки заказа параллельно несколькими человеками — количество проблем с 1С растет экспоненциально и оправдывает переход на более традиционную платформу (например Java). Мое наблюдение подсказывает, что разработчик WMS под 1С постоянно стоит перед выбором: то ли корежить процессы на складе под документальный подход 1С (не будем показывать пальцем, но у системы-образца любой чих на терминале сбора данных оформляется документом-заданием), то ли пользоваться 1С как тьюринг-полной системой программирования и писать нечто совершенно отличное от стандартной конфигурации. Но в последнем случае совершенно не очевидно, почему стоит выбрать платформу 1С (а не, например, Java). В последнем случае и инструментов выбор побогаче, и коллективная работа попроще, и другие плюшки имеются. Справедливости ради, если кто-то мне попытается продать идею писать бухгалтерию для РФ на Java вместо 1С — я его или выгоню, или застрелю, или и то и другое сразу. :-)
1С хороша там, где она хороша! То есть в бухгалтерии. Там она родилась, там ей пользоваться удобно. Пока Нургалиев входит во всякие советы при МНС и цифровой платформе, у них будет первый инсайд по формам и форматам обмена данными с госорганами, так что вариантов особо нет.

А вот когда пытаются 1С представить как платформу для автоматизации всего — это вызывает «в мирное время смех, в военное — панику» © из анекдота. Потому что 1С в стандартной конфигурации оперирует базовым понятием «документ», и точка. Нету документа — значит и события нет. И нет смысла бороться с этим бухгалтерским подходом! Хотите в режиме он-лайн управлять складом — ставьте WMS. Хотите продавать через сайт — ставьте интернет-магазин. А потом скидывайте в 1С результаты работы этих систем в виде документов. Хотите — раз в месяц. Хотите — раз в день, хотите — хоть в онлайн режиме!

А 1С потом по вашим документам сделает красивые проводки, налоговые регистры и формы для отчета в ИМНС, ФСС, и прочие богадельни. Если документы и справочник товаров/услуг сделать с умом, то по данным документального учета 1С можно заниматься финансовым анализом, распределять производственные затраты и тому подобное.

P.S. Вообще, концепция специализированных систем (при условии открытых интерфейсов, а лучше — исходников), кооперативно решающих сложную задачу — кажется мне гораздо более жизнеспособной, чем попытка сделать мегаплатформу «для всего», будь то 1C, SAP, Axapta/Dynamics, или что-то еще… Другое дело, что 1С нужен в первую очередь Vendor Lock-in, а не решение вашей бизнес-задачи.
Ну… Если предположить что после выгорания твердотопливных ускорителей (SRB) они повреждают внешний бак (ET) но не сам шаттл — то судя по следующей диаграмме, они потеряют три основных двигателя (SSME), и будут вынуждены выполнять Contingency abort с опцией bailout. Это, конечно, не штатная посадка в шарике Союза, а цирк с выездом на кривой палке и приземлением на парашюте в воду. Но шанс выжить есть.

image
Любой статический анализатор лучше натравить, я думаю…
Два момента. Первое: тесты бывают разные, и падают они по-разному: один тест может упасть потому что не прошла валидация выходных параметров (ассерты), а другой, посложнее, может и с экспешеном в недрах завершиться. И, насколько видно, сейчас бот охотится именно за последними исключениями. Второе: если начать фантазировать — то ботофикс для второго теста будет выглядеть примерно так: if(x==3 && y==2) return(1.5) — он же бот и не думает, правда. Я не очень знаю систему типов питона, поэтому предполагаю что этот ботофикс ничего не даст, и бот его откатит. Но это сложный случай, потому что нужно менять тип возвращаемого значения. А вот замазать NullPointerException путем оборачивания строчки в if(object!=null) {упавший_код;} еще как автоматически можно. При этом, конечно, проблема не переданного объекта никуда не исчезает — она вытесняется за границу теста. То есть тест не падает, а после деплоя в продакшн с этим эксепшеном падает сразу все приложение.
И еще одна мысль. Распространение таких ботов покончит с тестированием кода. Потому что если тест выявляет проблему — это повод задуматься, откуда она взялась. Может ли в этой точке объект быть null? Если нет, то почему это не было проверено раньше? Если да, то где еще он используется — и проверяется ли он на null там, и т.д. То есть упавший тест, в идеале, сообщает нам о наличии некоторой системной проблемы — которую следует обнаружить и разрешить. А после прохода бота, у нас тесты-то будут все зелененькие, но программа продолжит падать — потому что тесты больше ничего не тестируют. Они с обратной стороны аккуратно закрыты ботовыми заглушками!
Причем, в одном случае люди потом вынесли проверку за цикл, а в другом случае — это действие, фактически, маскирует проблему с конфигурацией программы. В этой ситуации, неудивительно, что люди не различили робота перед собой — лечением симптомов проблемы одинаково занимался бы и программист и ИИ. В общем, создается впечатление, что авторы бота-программиста увидели обычную вежливость к незнакомому разработчику со стороны мейнтейнера, и навыдумывали себе на этой почве невесть что… А так, судя по-описанию, обычный rule-based ИИ. И правила, скорее всего, вручную пишут…
В идеальном мире нормы непротиворечивы, доступны, и исполняются всеми без исключения. А мир, в котором живем мы, увы — не такой. И, кстати, руководителей никто не уговаривал. Уговоры — это что-то из детства. Просто мудрые люди, насмотревшиеся на пожарах всякого, умели наладить сотрудничество. Штрафовать и выдавать предписания они тоже вполне умели. Но большинство людей вполне адекватно воспринимали посыл: «Я помогаю вам (!) защитить и спасти ваши (!) жизни и ценные вещи». Психологию нельзя сбрасывать со счетов, пока речь идет о людях. Не зря же, например, в авиации при наличии инструкций и руководств (зачастую, намного более конкретных чем у пожарной охраны) занимаются CRM (crew resource management, в вольной интерпретации — наукой по обеспечению рабочей обстановки в кабине экипажа). Потому что только абстрактный пилот в вакууме всегда все помнит и действует строго по инструкции. А реально за штурвалом — люди…
Вот тут тонкий момент. Такие трагедии происходят в том числе и потому, что инспекторы МЧС в массе своей не ориентированы на профилактическую работу. Если ты приходишь к ним с вопросом — в ответ тебе в лучшем случае делаются случайные выписки из нормативных документов, и понимай как хочешь. И это совершенно сознательная политика — не брать на себя ответственность за разъяснения. Типа читайте законы и нормы, там все написано (и пофиг что некодифицировано и противоречиво). А когда выходит проверка, то она по внутренним регламентам должна быть результативной — читай привести к акту с замечаниями и штрафам в бюджет. В результате, руководитель предприятия и МЧС смотрят друг на друга волками, и мероприятия по пож.безопасности выполняются по принципу «на, подавись». Хотя кое-где еще до недавнего времени оставались сотрудники (в основном, еще старой закалки), которые ходили по предприятиям и умело и спокойно разговаривали. После этих разговоров руководители проникались, и даже учения по пожарной тревоге начинали проводиться «для себя, а не для галочки». Разумеется, такой импульс тоже не вечен (у руководителя много за что голова болит кроме пожарки) — но и инспектора были не промах: совсем с горизонта не никогда пропадали…
Согласен, там где критична температура — ABS и Нейлоны. Но печать нейлоном — это ой! Начиная от хранения/сушки и заканчивая усадкой. Обычно этого удается избежать.
То есть дегазацию компонентов под вакуумом не делаете? И как оно проливается? Дефектов не очень много? Мелкие детали не страдают?
Подозреваю, что маркетинг — увеличение высоты как самый дешевый способ улучшить цифры в брошюре (печатный объем XXX куб.см.). И с инженерной точки зрения, увеличение Z ничего не стоит — она самая медленная и рабочий ход только в одну сторону. А делать длинную каретку — тут и масса, и прогиб, и все что угодно. Вот и не делают…

Information

Rating
1,493-rd
Registered
Activity