Программа передается как есть

Вся информация, необходимая декодеру для обработки принятого цифрового потока и выделения нужных компонент программы, сосредоточена в данных управления (их еще называют метаданными), передаваемых в полях адаптации непосредственно после четырехбайтных заголовков пакетов транспортного потока MPEG-2.

Метаданные организованы в виде нескольких таблиц, содержащих сведения о составе программ и идентификаторах их компонентов, которые называются таблицами программно-зависимой информации PSI (Program Specific Information).

Каждая из них передастся в транспортном потоке в пакетах с определенным РШ. Кроме того, все таблицы имеют контрольную сумму (каждая свою), поэтому всегда можно определить, правильно передана таблица или нет. Во всех таблицах есть поля с информацией и дескрипторы, то есть особым образом структурированные данные описательного характера.

Алгоритм действий декодера MPEG-2 цифрового телевизора при прочтении таблиц PSI поясняется рис. 3.23 [ 14].

Как передается программа одиночества

Рис. 3.23. Схема функционирования декодера MPEG-2 при анализе метаданных

Рис. 3.24. Формат таблицы РАТ: а — общая структура таблицы; б — структура заголовка

Рассмотрим структуру таблиц подробнее. Общий формат таблицы РАТ показан на рис. 3.24 а. Она содержит заголовок длиной 8 байт, поле данных и символы проверки циклическим избыточным кодом CRC (Cyclic Redundancy Check).

На использовании данных CRC основан метод обнаружения ошибок в передаваемом сообщении, заключающийся в сравнении остатков от деления блоков кодовой последовательности на фиксированный делитель воспроизводимый как на передающей, так и на приемной стороне. Структура заголовка таблицы РАТ более детально показана на рис. 3.24 б. Первым идет идентификатор таблицы table_id.

Это однобайтовое слово обязательно входит в состав любой таблицы и определяет ее тип. Таким образом, таблица РАТ имеет два идентификатора: P1D и table_id, из которых PID является более общим указателем. Следующий существенный элемент заголовка — определитель длины секции в байтах, в котором два старших бита из 12 установлены на «0», так что длина секции нс может превышать 1024 байта.

Идентификатор транспортного потока trans- port_stream_id размером 2 байта указывает условный номер в данной сети транспортного потока, в котором передастся анализируемая таблица. Указатель «номера версии» изменяется на единицу каждый раз. когда в таблицу вносятся изменения. Если таблица разбита на несколько секций, однобайтовый указатель «номер секции» сообщает номер передаваемой секции. «Номер последней секции» необходим для подтверждения того, что вся таблица принята декодером.

В поле данных таблицы РАТ содержатся сведения о программах, передаваемых в транспортном потоке, с их номерами PID. «Номер программы» занимает два байта, затем следует трехбитовый промежуток и 13- битовое значение PID.

ВАЖНО! Вот ТРИ запаха рака, на которые люди не обращают внимание! Чем пахнет рак (онкология)?

Таблица РМТ создастся отдельно для каждой программы, передаваемой в транспортном потоке. Общая структура таблицы показана на рис. 3.25 а, детальная структура заголовка на рис. 3.25 б. Из рис.

3.25 а следует, что в состав таблицы РМТ входят заголовок длиной 12 байт, поле данных переменной длины и символы синхронизации, называемые «ссылкой на программные часы» (PCR — Program Clock Reference, то есть временной штамп программных часов). Дело в том, что транспортный поток может содержать программные компоненты с разной предысторией, в том числе и с несколько различающимися тактовыми частотами, поэтому невозможно или весьма ?трудоемко привести все сиг налы к единой временной базе.

Для управления такими потоками вводится дополнительный механизм синхронизации PCR. Непосредственно символы PCR, как и другие временнь’ю метки, представляют собой 33-битовос число, отсчитываемое в периодах частоты 90 кГц, получаемой делением на 300 частоты тактового генератора 27 МГц. Оно показывает ожидаемое время завершения считывания в декодере поля PCR из транспортного потока, после чего декодер может приступить к сравнению пришедшего и местного отсчетов и выработке корректирующего сигнала. Особо следует отметить, что PCR вводится в транспортный поток на программном уровне, в одном потоке могут передаваться несколько различных PCR, по числу программ, и декодер MPEG-2 при переключении на каждую новую программу заново синхронизирует свой внутренний генератор частоты 27 МГц. Стандарт MPEG-2 предписывает повторение метки PCR нс реже чем 1 раз в 0,7 с. В промежутках декодер вычисляет значения меток синхронизации путем интерполяции.

Рис. 3.25. Формат таблицы РМТ: а — общая структура таблицы; б — структура заголовка

Основными компонентами таблицы CAT являются уже знакомый tablejd и дескриптор системы условного доступа — указатель, сообщающий декодеру условное обозначение используемой в транспортном потоке системы условного доступа и номер P1D потока управляющих сообщений о правах доступа. Дескриптор условного доступа может присутствовать и в РМТ таблице, в этом случае он указывает на PID потока сообщений, необходимого для дешифровки скремблированной программы.

Частота повторения пакетов РАТ и РМТ таблиц должна быть не менее 10 Гц, периодичность сообщений условного доступа определяется конкретной системой условного доступа.

Дополнительная сервисная информация (SI — Service Information) служит для описания технических атрибутов каждой из доступных служб, предоставляемых индивидуальными вещателями. Она необходима для того, чтобы пользователь мог идентифицировать службы и события, переносимые различными мультиплексами по различным сетям. Данные SI структурированы в одиннадцать таблиц (SDT, EIT, TDT. BAT, RST, ТОТ, ST, SIT, DIT, TSDT, NIT) [141:

• • SDT (Service Description Table): таблица описания службы — описывает различную дополнительную информацию, передаваемую в транспортном потоке; содержит перечень названий служб, провайдеров услуг и других параметров, ассоциированных с каждой службой в конкретном мультиплексе стандарта MPEG-2;
• • EIT (Event Information Table): таблица информации о событиях — содержит сведения обо всех событиях или программах в мультиплексе MPEG-2: наименование сюжета, время его начала, продолжительность и пр. (как для текущего транспортного потока, так и по опциям для других транспортных потоков, которые может принять телевизор, то есть для других типов обслуживания);
• • TDT (Time and Date Table): таблица времени и даты — используется для передачи информации точного времени, включая текущее время и дату, служит для подстройки внутреннего синхрогенератора цифрового телевизора. Данные TDT передаются в отдельной таблице по причине частого обновления этой информации. Данная таблица содержит также информацию о всемирном координированном времени (UTC — Universal Time Coordinated), которое может быть использовано для обновления текущего времени в цифровом телевизоре. Таблица укладывается в одну секцию длиной 66 байт. К таблице TDT тесно примыкает таблица ТОТ;
• • ТОТ (Time Offset Table): таблица смещения времени — несет информацию, относящуюся к текущему времени и дате и к смещению местного времени отноеитсльно UTC для разных регионов страны. Этот сдвиг может быть использован для расчета и индикации местного времени на табло телевизора или в электронном путеводителе по программам. Значения сдвига уточняются при переходе от зимнего времени к летнему и обратно. Данные ТОТ передаются в отдельной таблице, по причине частого обновления содержащейся в ней информации. Таблицы ТОТ и TDT передаются в пакетах е одинаковым PID. Поэтому их различение осуществляется по идентификатору таблицы;
• • BAT (Bouquet Association Table): таблица группы служб — содержит информацию о группировке служб в одной программе, то есть одновременно декодируемых и выдаваемых пользователю; сообщает название группы и предоставляет перечень служб в каждой группе (конкретная служба может принадлежать одной или большему числу групп служб). Это позволяет пользователю работать с меню программ данной сети и выбирать интересующую его службу, нс используя сведений о частоте настройки и других параметрах потоков;
• • RST (Running Status Table): таблица текущего статуса — ее секции используются для быстрого обновления текущего статуса одного или нескольких событий (исполняется/нс исполняется); секции таблицы RST посылаются только однажды — в момент изменения статуса события в отличие от других таблиц SI, которые обычно передаются е циклическим повторением; данные таблицы RST позволяют автоматически переключаться между событиями;
• • ST (Stuffing Table): таблица байт стаффинга — используется для замены или отмены действия существующих секций (либо субтаблиц, либо полных таблиц SI), в частности, граничных секций;
• • SIT (Selection Information Table): таблица выбираемой информации — используется только в «частичных», то есть в записанных потоках бит; она несет сводку об информации SI, требуемой для описания потоков в частичном потоке бит;
• • DIT (Discontinuity Information Table): таблица неоднородности информации — используется только в «частичных», то есть в записанных потоках бит; выводится в случае, когда информация SI в частичном потоке бит может быть неоднородна;
• • TSDT (Transport Stream Description Table): таблица описания транспортного потока;
• • NIT (Network Information Table): таблица сетевой информации — содержит имя сети, к которой относится данный транспортный поток, и перечень остальных транспортных потоков е указанием наземных каналов, по которым эти транспортные потоки передаются. Под сетью понимается совокупность транспортных потоков, передаваемых в одной системе доставки (например, одной вещательной компанией).

Фактически таблица NIT имеет два вида: actual и other, что связано е

мультиплексированием. NIT actual — это таблица для текущей сети связи.

сгенерированная мультиплексором данной сети. NIT other предназначается для другой сети. Передача обеих таблиц NIT возможна только в том случае, если при мультиплексировании используется N1T другой сети и в нее вносятся изменения.

Для примера в табл. 3.5 перечислены значения идентификатора программ PID, которые должны использоваться для пакетов транспортного потока, переносящих секции сервисной информации SI.

В стандарте DVB-Т используются ограничения следующего вида:

• • Каждая секция таблицы взаимосвязи программ РАТ и таблицы структуры программы РМТ должна передаваться, по крайней мерс, раз каждые 100 мс.
• • Таблица сетевой информации NIT вводится в транспортные пакеты ео значением идентификатора PID 0x0010. Каждая еекция таблицы NIT должна передаватьея по крайней мере один раз каждые Юсе минимальным интервалом времени 25 мс между последним байтом данной секции и первым байтом следующей передаваемой секции.
• • Таблицы PSI передаются в соответствующем потоке бит последовательно без промежутка между отдельными таблицами. Так как таблицы нс обязательно должны начинаться в начале транспортного пакета, то индикация их местоположения обеспечивается е помощью поля poin- tcr_field, которое указывает число байт, которые следуют за ним перед началом таблицы PSI. Значение поля pointer_ficld, равное 0x00, указывает, что новая таблица PSI последует за ним непосредственно.
• • Таблица взаимосвязи программ РАТ передается как полезная загрузка битового потока с РШ = 0. Таблица РАТ обеспечивает соответствие между номером программы и значениями идентификаторов РШ в пакетах транспортного потока бит, содержащих описание программы в таблицах РМТ.

Значения идентификаторов PID для потока информации SI

Источник: ozlib.com

Принцип «As is» и защита прав покупателя ПО

настоящее время большинство программ в мире продается по принципу «As is» («Как есть»). В результате за проблемы, возникающие в процессе эксплуатации или установки программы, разработчик и распространитель ответственности не несут: они уже сделали все возможное, чтобы таких проблем не возникало. Проще говоря, разработчик программы не отвечает за ее работу.

Кажется, что подобное утверждение противоречит здравому смыслу. Однако принцип «As is» — это общепринятое положение в мировой компьютерной практике. Давайте рассмотрим юридическую сторону продажи программ.

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

Итак, лицензия на ПО предоставляет официальное право на использование конкретной программы. Условия лицензии фиксируются в лицензионном соглашении конечного пользователя (End User License Agreement, EULA).

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

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

Большинство лицензионных соглашений прямо запрещает передачу программного обеспечения во временное пользование или предоставление в аренду.

Многие разработчики ПО используют лицензионное соглашение для ограничения прав потребителя. Разработчик ПО предполагает, что покупатель, приобретая лицензию по принципу «As is», получает программный продукт со всеми имеющимися в нем ошибками и, следовательно, не вправе требовать возмещения ущерба, причиненного его применением. Обычно в подобной лицензии материальная ответственность производителя ограничивается суммой, уплаченной покупателем за программный продукт. Разработчик и распространитель, как правило, не несут ответственности и за утерю пользователем баз данных программы и не производят ее восстановления.

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

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

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

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

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

Сегодня во многих системах от работы ПО зависит человеческая жизнь. Как насчет ПО для ядерных реакторов, медицинских инструментов, управления безопасностью автомобиля, производства лекарств? Вы согласны с тем, что его производители не будут нести ответственности за работу своих программ?

Смертельное лекарство, авария на атомной электростанции по вине разработчика ПО… Неужели в ближайшем будущем все это произойдет? Нет, это реальность настоящего дня! Известен случай, когда в результате ошибок, допущенных при разработке ПО для медицинского прибора, погибли люди, для лечения которых он применялся.

Компьютеры и вычислительные устройства все больше вторгаются в нашу жизнь. Мы всё сильнее зависим от программного обеспечения и полагаемся на его надежную работу. Неужели происшествия, связанные с некачественным ПО, должны стать нормой, чтобы мы задумались? Или уже настало время признать, что качество — это неотъемлемая часть ПО?

Производители ПО должны нести ответственность за свои продукты. Баги в программах — это не неудобства, а дефекты, которые требуется устранить. Давайте представим себе другой мир, в котором на программах, продаваемых по принципу «As is», имеется яркая наклейка «Производитель данной программы не гарантирует ее корректную работу» или «Использование этого ПО может быть вредно для вашего здоровья». А в выпуске новостей, например, передают сообщение о том, что корпорация «Макрософтвер» отзывает 422 млн. копий своего продукта Home XP из-за проблем с печатью документов и гарантирует покупателям возмещение материального ущерба. Не пора ли нам задуматься над тем, как претворить эти мечты в жизнь?

• ПК и комплектующие

• Настольные ПК и моноблоки
• Портативные ПК
• Серверы
• Материнские платы
• Корпуса
• Блоки питания
• Оперативная память
• Процессоры
• Графические адаптеры
• Жесткие диски и SSD
• Оптические приводы и носители
• Звуковые карты
• ТВ-тюнеры
• Контроллеры
• Системы охлаждения ПК
• Моддинг
• Аксессуары для ноутбуков

• Принтеры, сканеры, МФУ
• Мониторы и проекторы
• Устройства ввода
• Внешние накопители
• Акустические системы, гарнитуры, наушники
• ИБП
• Веб-камеры
• KVM-оборудование

• Сетевые медиаплееры
• HTPC и мини-компьютеры
• ТВ и системы домашнего кинотеатра
• Технология DLNA
• Средства управления домашней техникой

• Планшеты
• Смартфоны
• Портативные накопители
• Электронные ридеры
• Портативные медиаплееры
• GPS-навигаторы и трекеры
• Носимые гаджеты
• Автомобильные информационно-развлекательные системы
• Зарядные устройства
• Аксессуары для мобильных устройств

• Цифровые фотоаппараты и оптика
• Видеокамеры
• Фотоаксессуары
• Обработка фотографий
• Монтаж видео

• Операционные системы
• Средства разработки
• Офисные программы
• Средства тестирования, мониторинга и диагностики
• Полезные утилиты
• Графические редакторы
• Средства 3D-моделирования

• Веб-браузеры
• Поисковые системы
• Социальные сети
• «Облачные» сервисы
• Сервисы для обмена сообщениями и конференц-связи
• Разработка веб-сайтов
• Мобильный интернет
• Полезные инструменты

• Средства защиты от вредоносного ПО
• Средства управления доступом
• Защита данных

• Проводные сети
• Беспроводные сети
• Сетевая инфраструктура
• Сотовая связь
• IP-телефония
• NAS-накопители
• Средства управления сетями
• Средства удаленного доступа

• Системная интеграция
• Проекты в области образования
• Электронный документооборот
• «Облачные» сервисы для бизнеса
• Технологии виртуализации

Источник: compress.ru

Описание бизнес-процессов «Как есть» (AS IS) и «Как должно быть» (TO BE)

Когда я сам изучал моделирование бизнес-процессов при реинжиниринге, то во всех учебниках встречал два понятия — AS IS и TO BE. И все авторы писали, что сначала необходимо составить нотацию AS IS (буквальный перевод — «как есть»), т.е. как система работает в настоящее время, и только потом приступать к процессу модернизации, т.е. создавать нотацию TO BE (Как должно быть).

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

Описывать нечего

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

Здесь нет ничего необычного. Каждый человек мыслит немного по-своему, у каждого за плечами — собственный опыт. В результате даже самые простые задачи мы все склонны выполнять по-разному.

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

Еще ярче, в тех же продажах, заметна разница между действиями при работе с лидами:

• Один менеджер отправит прайс-лист или коммерческое предложение и успокоится на этом.
• Другой сначала позвонит, все уточнит.
• Третий будет добиваться личной встречи даже там, где без нее можно прекрасно обойтись.

Перед ними стоит задача — обработать лиды и сделать план продаж. Возможно, есть даже перечень рекомендаций, как это лучше делать. Но единой системы нет. И люди начинают нарушать последовательность действий, поступать на свое усмотрение и т. д.

Даже при наличии должностных инструкций в реальности они чаще всего пылятся всеми забытые, а сотрудники работают «кто как привык». В итоге, мы видим, что системы AS IS, т.е. «как есть», не существует. Нет какой-то единой системы, по которой на самом деле люди работают. И описывать, на самом деле, нечего.

Вы, конечно, можете, попытаться составить модель AS IS на основе инструкций. Но она не будет отражать реальность, ведь их массово нарушают. Можете опросить сотрудников, но любая из моделей будет отражать работу только части людей либо что-то «усредненное», что вообще не будет иметь отношения к реальности, т.к. все работают похоже, но — не так.

Описывать незачем

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

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

Зачем создают нотации AS IS?

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

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

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

Конечно, вы будете вести свои записи. Вполне возможно, что вы даже оформите их в виде нотации, как это и описывают в учебниках. Вы можете использовать эти записи для уточнения каких-то моментов в работе компании. Но этот этап нужен вам, а не заказчику.

Потому не имеет смысла тратить силы и время на составление полноценной нотации AS IS с сопроводительной документацией, включать этот этап в план работ и т. д. Если ваш клиент не ждет от вас этого этапа в обязательном порядке, что иногда случается в крупном бизнесе или в случаях, когда заказчики тоже читали те самые учебники, предоставляйте сразу решение — TO BE. Вы должны быть на стороне клиента, и давать ему то, что реально нужно. Это подход продуктивности.

‍Пример использования нотации AS IS и TO BE

Я сотрудничал с хлебокомбинатом, который имеет цех выпечки, склад и подразделение охраны. При составлении нотации AS IS стало очевидно, что участие охраны в процессе выпечки хлеба абсолютно не нужно.

Как выглядит процесс:

1. Сотрудники принимают материалы в цех. Операция выполняется вручную, момент принятия каких-либо документов здесь не отражается.
2. Пекут хлеб. Этот этап также не отражается в IT-системе. Хлеб они пекут вручную на оборудовании, которое не подключено к системе.
3. Составляют пакет документов “Выпуск хлеба”. Как именно выглядят эти документы, в данном случае не имеет значения.
4. Выполняют выпуск хлеба.
5. Далее они должны сдавать полученную партию и документы охране.
6. Охрана проверяет партию и дает разрешение. Причем, разрешение дается всегда, так как что может охрана? Убедиться, что в партии есть хлеб. Максимум – подсчитать его количество
7. Охрана выдает разрешение.
8. Цех выпечки передает партию товара на склад.
9. Склад принимает товар.

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

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

Процесс TO BE будет таким:

1. Сотрудники принимают материалы в цех. Операция выполняется вручную, момент принятия каких-либо документов здесь не отражается.
2. Пекут хлеб. Этот этап также не отражается в IT-системе. Хлеб они пекут вручную на оборудовании, которое не подключено к системе.
3. Составляют пакет документов “Выпуск хлеба”. Как именно выглядят эти документы, в данном случае не имеет значения.
4. Выполняют выпуск хлеба.
5. Цех выпечки передает партию товара на склад.
6. Склад принимает товар.

Источник: Блог компании Системный интегратор Тринион

Источник: biconsult.ru