Рассмотрим в качестве примера работу участка по производству сварных труб. Подробно работа участка описана здесь.
На участок поступает штрипс, штрипс устанавливается на разматыватель. Готовая труба собирается в пакеты.
Для того чтобы отразить работу этого участка в бизнес-приложении (например 1С) нужно создать документ ОПС (отчет производства за смену) в котором учесть списание штрипса и сдачу прокатанных пакетов. 1С рассчитает себестоимость каждого пакета распределив на них себестоимость штрипса.
Очевидно, что для этого потребуется дождаться сдачи всех пакетов изготовленных из этого штрипса. Это означает нам придется ради учетной схемы исказить фактическую картину производства.
Чем это может нам грозить?
Во первых: фактически произведенный пакет кладовщик может попытаться переместить например на склад. Если пакет не будет учтен в 1С кладовщик регистрируя транзакцию перемещения не получит подтверждения его наличия.
Во вторых: проблема может усугубиться если штрипс не успеют порезать к концу смены. Некоторые предприятия решают этот вопрос обязательной сдачей не порезанного штрипса на склад. Описанная проблема связана с тем что учетная схема большинства бизнес-приложений является агргированной. Т.е. фактически не рассчитанной на оперативный учет.
Какой выход я вижу в данной ситуации.
1. Инкрементальное обновление агрегированных документов.
Давайте рассмотрим описанный пример пошагово на примере 1С.
| |
|
| Устанавливается штрипс на разматыватель |
в 1С данный факт никак не отражается |
| Сдан первый пакет |
В 1С создается документ ОПС (отчет производства за смену) в списанные материалы попадает установленный штрипс и в сданном появляется первый пакет |
| Сдан второй пакет |
1С создается вторая строка после чего документ перепроводится |
Примечание: этот метод не является универсальным для всех бизнес-приложений. Например OEBS не дает такой возможности.
Второй подход состоит в том чтобы при сдаче пакета сразу формировать документ. Для этого в документ списывается часть штрипса по весу.
