Портфолио

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

1. Подготовка данных для налоговой в рамках встречной проверки.

Описание задачи.

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

    Бухгалтер организации N, каждый раз при поступлении такого запроса от налоговой, вынуждена тратить 2 недели своего рабочего времени на ручной сбор, анализ и сопоставление всей этой информации для составления единого отчёта. Более того, в процессе сбора этой информации привлекаются помощники бухгалтера, которые «поднимают» бумажные версии всех документов для проверки данных.

    Задача заключалась в том, чтобы написать дополнительный внешний отчёт, который выводил бы информацию, которую просит налоговая.

Решение задачи.

Задача разбивается на несколько этапов.

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

    Второй этап: выяснить у каких поставщиков была куплена номенклатура в том количестве из таблицы №1 и по какой цене. Одна и та же номенклатура могла быть куплена у нескольких поставщиков по разной цене в разном количестве. Следовательно, нужно узнать не просто поставщика, нужно узнать из какой именно партии были проданы те, условно, 10 единиц товара. Причём, по требованию заказчика, делать это нужно, используя метод LIFO (Last In First Out — Последним Пришёл Первым Ушёл). То есть, считать товар, поступившим на склад последним, проданным в первую очередь. Используя данный метод, составляется таблица №2.

    Третий этап: соединить по номенклатуре таблицы №1 и №2 в единую таблицу и вывести эти данные в форме отчёта в формате, заданном заказчиком с нужными группировками, наименованиями строк и столбцов.

Экономический эффект.

    Время формирования отчёта составило 3 минуты. То, что раньше требовало 2 недели рабочего времени бухгалтера и ещё нескольких помощников стало требовать 3 минуты машинного времени. Можно посчитать сколько денег стоит труд бухгалтера и его помощников в течение полумесяца и умножить это на число таких проверок в год, а потом умножить это ещё на 2-3-5 лет, чтобы получить полную картину. Дальнейшие комментарии излишни.

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

Описание задачи.

    Организация N имеет центральный склад и 4 розничных магазина. На складе находится порядка 15 000 наименований различного товара. От поставщиков товар попадает на центральный склад, а с центрального склада развозится по магазинам, где он продаётся. В среднем, в каждом магазине единовременно присутствует 7-8 тысяч наименований товара. Магазины начинают работу в 9 утра и закрываются в 7 часов вечера. На центральном складе есть сервер, на котором установлена конфигурация 1С Управление Торговлей 11, в которой ведётся весь учёт движения товаров и продаж. В магазинах стоят автономные кассы, которые каждый день после закрытия кассовой смены отправляют данные о продажах на заданную электронную почту. Утром следующего дня данные о продажах загружаются с электронной почты в базу 1С. Со стороны же 1С вечером каждого дня менеджером склада делается рассылка по магазинам информации по товарам и ценам для последующей загрузки этой информации на кассы силами менеджера магазина. Таким вот образом построен постоянный обмен информацией между центральным складом и магазинами.

    Задача заключается в том, чтобы выяснить соответствуют ли реальные остатки товаров в магазинах той информации об остатках, которая хранится в базе 1С по каждому магазину. Другими словами, вопрос в том, а не воруют ли продавцы? Именно этот вопрос мучал собственника. Хотя, справедливости ради, он понимал, что расхождения могут быть не только из-за того, что кто-то из продавцов что-то украл, а ещё и из-за того, что неверно были внесены данные в учётную систему (и это ответственность менеджеров склада), ну и со склада тоже могут своровать рабочие. Но склад то он под рукой, а вот магазины разбросаны все по городу и удалены. К тому же, какая-никакая инвентаризация по складу периодически велась, а вот полноценной инвентаризации магазинов не было никогда в силу многих причин.

    Основная проблема инвентаризации магазина с таким количеством товара в том, что просто некому и некогда её проводить. По хорошему, инвентаризация делается так: магазин полностью останавливает торговлю, например ночью (так все супермаркеты и делают), и за ночь команда людей проходит с терминалами сбора данных и «прощёлкивает» весь товар в магазине. Дальше информация с терминалов сбора данных сравнивается с информацией в учётной системе и формируются документы оприходования излишков и списания недостач товара с дальнейшим «разбором полётов». А утром магазин снова начинает свою работу.

    Такую команду инвентаризаторов, к тому же работающих ночью, могут позволить себе только крупные торговые сети. А небольшой сети из 4-х магазинов постоянно содержать этих людей просто не на что. И ладно бы ещё наименований товара было немного, можно было бы силами продавцов всё просчитать за вечер, но 7-8 тысяч позиций… это много, слишком много.

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

Решение задачи.

    Схема получается такой: работнику магазина даётся задача на день полностью просчитать энное количество позиций номенклатуры. Если в течение дня какие-то из этих позиций подвезли со склада, то их нужно отложить в сторону и не считать. Если какие-то из этих позиций захотел купить клиент, то перед тем как ему их продать, нужно их посчитать. Вечером работник должен отправить файл с данными на заданный электронный адрес, с которого на следующий день его заберёт учётная система 1С и сравнит с остатками на утро предыдущего дня только те позиции, которые считал работник. На следующий день всё повторяется и так до тех пор, пока работник не сообщит о том, что он всё закончил считать.

    Эту схему ещё называют «скользящей» инвентаризацией. И всё вроде красиво и хорошо, но вот вопрос, а как узнать все ли позиции из тех что надо было, работник действительно посчитал. Ну, мало ли, может забыл что-то. Шёл по списку и пропустил пару строк. На этот вопрос отвечу чуть позже.

    А пока что программная реализация данной задачи сводится вот к чему… Сначала нам нужно сформировать полный список товаров, которыми торгует организация. Это не сложно, вывести список номенклатуры. Причём нам нужны не наименования, точнее не только они. Самое главное, нам нужны штрих коды товаров. Наш работник магазина вооружён терминалом сбора данных (ТСД), который умеет считывать штрих код. И именно с помощью ТСД работник «щёлкает» товар. Для каждой позиции номенклатуры штрих код уникален. Другими словами, нам нужно сформировать текстовый файл со штрих кодами всей имеющейся номенклатуры в понятном для ТСД формате и отправить этот файл на электронную почту магазина, чтобы работник мог его загрузить в ТСД. Но вот что ещё нужно, так это сформировать файл для самого работника, в понятном ему формате, с разбиением товаров на группы, с полным наименованием и со штрих кодом для справки. Это и будет тот список, по которому он будет идти. Он может его распечатать и носить с собой для удобства или периодически в него подглядывать, чтобы видеть что ему считать дальше. Итого, каждое утро программа должна отправлять 2 файла на электронный адрес магазина. Один для ТСД, второй для работника. Причём формирование файла для работника должно вестись с учётом уже посчитанных им ранее позиций, этих позиций в файле быть не должно, чтобы он не путался.

    Зачем, спрашивается, каждый день отсылать для ТСД полную базу товаров? Это нужно только для того, что есть ненулевая вероятность того, что в ассортименте организации, пока идёт инвентаризация, появятся новые позиции товаров. И если информация о них не будет загружена в ТСД, то ТСД просто не опознает их.

    Не забываем, что магазинов у нас 4, у каждого свой адрес электронной почты и для каждого нужно сформировать свой уникальный набор из 2-х файлов, ведь у каждого магазина будет свой прогресс. Кроме того, в магазинах разные ТСД и каждый имеет свой формат хранения данных. В общем, делаем обработку с одной кнопкой, нажатие на которую приводит к автоматическому формированию нужных файлов с автоматической их отправкой по всем магазинам. Отправку делаем либо поздно вечером, когда все движения товаров по складам закончились, либо рано утром, когда они ещё не начались.

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

    Таким образом в учётной системе формируются документы «Пересчёт товаров» на каждый день инвентаризации по каждому из магазинов, которые содержат в себе информацию по расхождениям между фактическим и учётным количеством товаров. Когда магазин заканчивает инвентаризацию и работник присылает нам последний файл мы должны выяснить, а все ли позиции он действительно посчитал. Для этого мы составляем список №1 всех пересчитанных товаров. Данные берём из документов «Пересчёт товаров» по данному магазину. Затем составляем список №2 всех товаров, которые, согласно учётной системе должны были быть в магазине на дату начала инвентаризации плюс те товары, которые должны были быть на остатках магазина по ходу инвентаризации. Затем сравниваем список №1 и список №2. Если в результате сравнения обнаружились товары, которые пропустили в ходе инвентаризации, то автоматически формируем список этих товаров и отправляем на пересчёт.

    Вообще, было бы не плохо, отправить на пересчёт не только товары, которые вообще не считали, но и те товары, по которым обнаружились расхождения. Ну, мало ли, человеческий фактор, не так и не то посчитали, не туда нажали и т.д. Поэтому их тоже включаем в список товаров для пересчёта. Пересчётов можно сделать вообще несколько, но 2-3 пересчёта вполне достаточно.

    Ну а дальше дело за малым, нужна печатная форма, которую я специально создал, назвав её «Итоговой ведомостью инвентаризации». Она собирает данные по всем расхождениям, выводится на печать и дальше подписывается материально ответственным лицом магазина с одной стороны и лицом, ответственным за данные учёта, с другой стороны. Распечатанная ведомость отправляется в магазин, подписывается работником(-ами) магазина, возвращается в центральный офис. Дальше попадает на стол руководителю, а он уже смотрит и принимает решение… То ли тут в массе своей получился пересорт товаров, то ли где-то в учёте кто-то что-то недопровёл, то ли действительно кто-то проворовался и такого человека нужно как минимум увольнять.

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

Экономический эффект.

    Тут сложно сказать, сколько именно в деньгах или времени выиграла организация от внедрения такой системы проведения инвентаризации. Это в первую очередь инструмент контроля, инструмент определения честности и добросовестности персонала. Определённо можно сказать лишь одно: наличие такого инструмента позволяет предупредить потери предприятия от небрежного ведения данных учёта и/или от воровства материально ответственными лицами. И, как следствие, этот инструмент позволяет собственнику бизнеса спать чуточку спокойнее =).

    С другой стороны, можно посчитать в какие деньги обошлась бы команда инвентаризаторов с ТСД для каждого из них, если решать эту задачу традиционным способом. Эта команда должна успеть просчитать весь магазин за одну ночь и делать это пару-тройку раз в месяц для каждого магазина. При этом они ещё должны грамотно разбивать свою работу на участки, чтобы не получилось такого, что один и тот же товар считают 2 разных человека. Это значит, что кто-то ещё должен управлять ими и руководить ходом работ. Из практики... один человек за 10 часов способен «прощёлкать», если сильно постарается, ну где-то позиций 300 от силы. Значит на пересчёт магазина за ночь, где пусть будет 7 тысяч позиций номенклатуры, нужно будет, согласно расчётам 23 человека. Ок, магазин не работает с 7-ми вечера до 9-ти утра, а это не 10, а 14 часов (что как бы больше длительности стандартных рабочих 8-ми часов аж на 75%) времени для полной инвентаризации. За это время весь магазин успеют просчитать 16 человек+ управленец, итого 17. Ну и да, работа у них не каждый день, но 3 раза в месяц, 4 магазина, это 12 рабочих ночей по 14 часов безотрывного пересчёта. А учитывая, что им как минимум нужно ночь работать, сутки отдыхать, то получается весь рабочий месяц. Меньше чем тысяч за 20-25 (в регионах) вряд ли кто согласится работать так. А это 340 — 425 тысяч рублей каждый месяц расходов (если з.п. чёрная, а если белая - прибавляйте отчисления в фонды, отпускные, больничные и это я ещё стоимость ТСД оборудования не учёл для 16-ти человек), что равняется месячной прибыли одного магазина, а то и двух сразу. Так что да, экономический эффект есть, и весьма не иллюзорный.

    Да и вообще, по-моему, достаточно лишь того факта, что без этой системы, полная инвентаризация в рамках данного предприятия (и многих похожих других) просто была бы невозможной. К слову, сделав пару раз полную инвентаризацию всех магазинов и уволив по результатам пару сотрудников, собственник попросил меня сделать упрощённый вариант инвентаризации лишь только выборочных групп товаров. Всё-таки полная инвентаризация дело долгое, реально занимает до месяца времени и сильно загружает сотрудников магазина, а выборочную можно сделать быстро, тем самым давая понять продавцам, что расслабляться им там не надо, потому что могут «попасть». Теперь у собственника бизнеса есть целых 2 инструмента контроля =)

3. Формирование меню питания детского сада.

Описание задачи.

    Каждый день в детском саде Х помощник бухгалтера составляет меню питания детей на следующий день. Это меню относится поварам, и утром следующего дня они готовят еду на детей и сотрудников, согласно этому меню. Меню включает в себя не только перечисление блюд, но и перечисление необходимых для их приготовления продуктов в необходимом количестве, с учётом планируемого количества детей и сотрудников.

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

    Задача заключается в том, чтобы, зная набор блюд на следующий день (из десятидневного цикла), рассчитать необходимое количество продуктов для их изготовления, согласно нормам, на всех детей и сотрудников. После такого расчёта дать возможность внести ручную поправку на случай, если какого-то продукта завезли больше/меньше нормы, и вывести меню по заданной форме на печать. Для справки: каждый день помощник бухгалтера на составление меню тратит около двух часов рабочего времени.

Решение задачи.

    Для решения задачи я создал новую конфигурацию, которую так и назвал: «Меню питания детского сада». В рамках этой конфигурации я сделал несколько справочников, один документ и пару печатных форм. Самым базовым справочником стал справочник продуктов, который просто содержит в себе наименование продукта (мясо, соль, молоко и т.д.) На основе справочника продуктов был построен справочник блюд. Справочник блюд содержит в себе наименование блюда а также продукты, из которых готовится блюдо, с необходимым количеством, согласно нормам. Далее по иерархии идёт справочник десятидневного меню. Он содержит в себе номер дня (от 1 до 10) и набор блюд в этот день с разбиением на завтрак, второй завтрак, обед и полдник. Ну и заканчивает эту цепь документ, содержащий в себе информацию из всех этих справочников. В документе просто выбирается номер дня, вводится количество детей и сотрудников, и он автоматически заполняется блюдами выбранного дня и автоматически вычисляется количество всех необходимых продуктов. Далее, если нужно, можно внести правки вручную. Документ сохраняется в базе и выводится на печать. И всё, меню готово. Можно нести поварам.

Экономический эффект.

    Весь процесс формирования документа с выводом его на печать занимает от силы 2 минуты. То, что раньше занимало 2 часа в день, после автоматизации процесса стало занимать 2 минуты. Теперь грубо посчитаем экономию времени за год. Без двух минут 2 часа в день дают экономию в среднем 42-х часов в месяц(месяц это в среднем 21 рабочий день). Умножим на 12 месяцев, получим 504 рабочих часа в год или 3 календарных месяца (504 рабочих часа это 63 рабочих дня, 63 рабочих дня, если в среднем в месяце 21 рабочий день, то это 3 месяца). Вот так нехитрая автоматизация высвобождает 3 месяца времени в году. Хотя казалось бы, мы автоматизируем какую-то мелочь, каких-то там жалких 2 часа времени на составление меню ручками с калькулятором. А в пересчёте на год выходит очень недурно, уже совсем и не мелко. А год то пройдёт, начнётся второй, потом третий. И этот эффект будет только нарастать. К концу четвёртого года сэкономленным окажется целый рабочий год!

4. Поиск товаров с плохой динамикой продаж.

Описание задачи.

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

    В конфигурации Управление Торговлей есть так называемая XYZ классификация номенклатуры, где товар попадает в категорию X, если он продаётся стабильно и постоянно, в категорию Y, если есть какие-то тенденции в его продажах (например сезонность), и в категорию Z, если нет никаких тенденций и продажи такого товара нерегулярны. И, казалось бы, вот же оно… Всё что нужно сделать, провести XYZ классификацию, и на всё что попало в группу Z ввести дикие скидки, сделать распродажу. Но не всё так просто.

    Ведь если вдуматься, то даже товары попавшие в категорию X с точки зрения собственника бизнеса могут считаться плохо продаваемыми, если, например, год назад было куплено 100 единиц товара, а потом продажи шли со скоростью 1 единица в месяц. С точки зрения XYZ анализа этот товар стабильно продаётся каждый месяц, каждый квартал, каждое полугодие. Вот только толку то от таких продаж очень мало. Ведь за год было продано лишь 12% от изначальных запасов.

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

Решение задачи.

    Задачу я решил в виде внешнего отчёта с несколькими параметрами. Первый параметр это дата начала анализа данных. Это та дата, которая будет некой нулевой точкой отсчёта. Конечной точкой будет текущая дата. Таким образом, получаем период за который мы будем анализировать продажи. Второй параметры это процент продаваемости. 0% - означает, что товар вообще ни разу не продавался, 100% означает что весь товар, что был в наличии на дату начала периода был полностью продан.

    Далее естественным образом следует предположить, что анализировать данные по продажам мы будем только тех товаров, которые сейчас есть в наличии, ведь избавляться от того, чего и так нет, совершенно бессмысленно. То есть мы получаем список №1. Теперь нам нужно узнать каким был остаток каждого товара из списка №1 на дату начала. Если на дату начала остаток каких-то товаров из списка №1 был нулевой, мы их исключаем из рассмотрения, так как это может лишь означать, что в ассортименте они появились позже точки отсчёта и считать их плохо продаваемыми нельзя. Может товар месяц назад появился, или вообще только вчера. Итак, мы удаляем из списка №1 эти товары и у нас получается список №2. Вот с ним дальше и будем работать.

    Теперь нужно выяснить процент продаваемости. А для этого нужно выяснить сколько единиц каждой позиции номенклатуры было продано с даты начала отсчёта по текущую дату. Можно выбрать все документы продажи, либо обратиться к записям регистров накопления этих документов, не суть. Важно то, что из документов продаж мы можем получить общее количество проданного по каждой позиции номенклатуры. Если это количество превысило начальный остаток, то процент продаваемости превысил 100% и нас такие позиции не интересуют. Товар многократно обернулся и у него хорошая продаваемость. А вот всё, что ниже 100%, а если точнее, ниже процента продаваемости, заданного пользователем, попадает в список №3.

    Ну, а далее дело за малым, вывести данные списка №3 на экран в форму отчёта. Можно даже с картинками =) И с указанием процента продаваемости. Дальше пользователю остаётся лишь посмотреть на результат и задать процент, на который необходимо, по его мнению, снизить цены на эти товары. И, нажатием одной кнопки, будет создан документ установки цен для этих товаров. Точка.

Экономический эффект.

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

    Если же пытаться сравнивать и выяснять сколько времени высвобождает такая автоматизация, то тут конечно тяжело. Тяжело сравнивать то чего раньше вообще не было с тем что появилось =) Но теоретически, можно попытаться представить какой объём работы нужно проделать человеку, чтобы получить все данные по списку из более чем 10000 позиций, свести и сопоставить вручную… Я что-то сомневаюсь что даже за месяц можно уложиться. А вот выполнение отчёта укладывается в минуту машинного времени.

5. Учёт высушенных пиломатериалов.

Описание задачи.

    Деревообрабатывающий комбинат занимается производством изделий из древесины. Древесину на комбинат поставляют в виде распиленных досок разных сортов дерева (ель, сосна, лиственница, берёза и т.д.), сгруппированных в пачки по сорту древесины, по сечению и длине доски (38ммХ150ммХ3м, 38ммХ150ммХ6м,40ммХ100ммХ4.5м и т.д.). Прежде чем пустить пиломатериал в производство, его нужно высушить до приемлемых значений влажности. На территории комбината находится 4 огромных сушильных камеры. В эти камеры с помощью погрузчика загружаются пачки пиломатериала, камеры закрываются и далее процессом сушки управляет автоматизированная система (контролирует температуру, влажность, скорость циркуляции воздуха в камерах). После завершения сушки, камеры открываются и высушенный пиломатериал вынимается погрузчиком из камер и увозится в цеха.

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

    Каждый раз после загрузки камеры, оператору нужно свести данные журнала в единую таблицу. В этой таблице должно быть указано сколько и какой древесины было загружено в камеру. Например, в камеру было загружено 3 пачки сосны сечением 40ммХ120мм длинной доски 6 метров. Количество досок в каждой пачке 147 штук. Значит всего было загружено 147*3 = 441 доска или 441*0,04*0,12*6 = 12.7 метра кубических пиломатериала данного вида.

    Одна камера вмещает в себя до 40-ка пачек. Условно там может быть 10 пачек ели разного сечения, 20 пачек сосны разного сечения и ещё 10 пачек лиственницы. Это 40 записей в журнале оператора по одной камере. И все их нужно свести условно к 5-ти типо-размерам пиломатериала с указанием объёма в метрах кубических. Этот процесс у оператора занимает до получаса времени рассчётов, сидя с калькулятором над журналом в руках, практически каждый день, ибо почти каждый день происходит загрузка освободившейся камеры.

    В конце каждой недели начальство запрашивает у оператора данные по общему объёму высушенного пиломатериала за неделю (это ещё 15 минут времени оператора). Тоже самое за месяц и за квартал. Кроме того, к оператору постоянно приходят начальники цехов и запрашивают информацию о том сколько и чего и в какой камере находится, когда было загружено, когда будет высушено, сколько и чего осталось в камере, если она разгружается в данный момент и так далее. Это им нужно для планирования своей производственной деятельности. И все эти запросы тоже съедают время оператора (5-10 минут в день). В сумме, уходит около часа рабочего времени на работу с данными каждый день.

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

Решение задачи.

    На базе платформы 1С я создал конфигурацию в рамках которой создал 2 справочника и 1 документ. Один из справочников содержит в себе информацию по видам сечений и длин досок, второй по сортам древесины. Документ же содержит в себе информацию о номере камеры, о датах её загрузки и выгрузки, о начальной и конечной влажности древесины. Табличная же часть документа содержит в себе строки с сортом древесины, сечением и количеством досок. Там же, внутри документа можно посмотреть сводную таблицу с типо-размерами загруженного пиломатериала и вычисленном автоматически объёмом в метрах кубических.

Информация по текущему состоянию камер выводится в специальной печатной форме:

Ну и информация о суммарном объёме высушенного пиломатериала за текущую неделю, месяц, квартал выводится в диалоговом окне:

Экономический эффект.

    Единственное, что в данном решении съедает время оператора, это заполнение документа информацией о загруженных пачках в камере. Но ввод этой информации максимально облегчён, поэтому перенос информации с бумажного журнала в документ не занимает больше 5-ти минут времени. В остальном идёт чистая экономия времени. В среднем, минут 50 рабочего времени каждый день. Внедрение этого решения высвобождает больше месяца рабочего времени в году. Что, на мой взгляд, весьма достойно, учитывая то, что реализовать и внедрить это решение совсем не сложно.

Можно  дальше продолжить, но, мне кажется, этого вполне
достаточно, чтобы решить для себя, могу ли я
быть полезным в решении Ваших задач.