Для начала «почти анекдот» на тему «чем отличается опытный консультант от неопытного»:
Неопытный консультант приходит к клиенту, смотрит на настройки системы и говорит: «Что это у Вас здесь за ерунда в настройках? Сейчас мы быстро всё исправим»
Опытный консультант приходит к клиенту, смотрит на настройки системы и говорит: «Что это у Вас здесь за ерунда в настройках? Но, раз так сделано, значит кому-то это было нужно»
Я, как опытный консультант 🙂 всегда придерживаюсь второй точки зрения, однако это не помешает мне критически отнестись к некоторым решениям и поделиться с Вами своим мнением.
У одного из моих клиентов очень продуманная система кодировки запасов, групп и категорий продукта, прозрачная система организации складов. Речь идёт о гостиничном бизнесе, поэтому большое внимание уделено таким группам запасов как еда, напитки, табачные изделия, всё остальное. В упрощённом виде выглядит это примерно следующим образом:
- Кодировка запасов: коды запасов, относящиеся к еде (FOOD), начинаются на 1. Коды запасов, относящихся к напиткам, начинаются на 2, на 3 начинаются коды запасов табачных изделий, на 4 — всё остальное
- Внутри имеются более точное деление на группы, например, мясо, хлеб, чай и т.д.
- Склады также начинаются на соответствующие цифры: основной склад продуктов (еда) — 100, основной склад напитков — 200, основной склад табачных изделий — 300. Кроме этого имеются склады, ассоциированные с ресторанами и барами, например, кухня основного ресторан (Код департамента 2010) — виртуальный склад 110 (1 — еда и 10 — 2 последние цифры кода департамента, всё очень логично и прозрачно), бар основного ресторана — виртуальный склад 210 — (2 — напитки и 10 — 2 последние цифры кода департамента)
В карточке каждого виртуального склада указан бухгалтерский счёт конкретного типа запасов, например, для кухни главного ресторана бухгалтерский счёт: 131110 — Inv: Food Main Restaurant (Запасы — еда Главный ресторан) и код департамента, например, 2010 — Главный ресторан, а для бара главного ресторана, соответственно, бухгалтерский счёт: 132210 — Запасы, напитки, Главный ресторан и тот же самый код департамента: 2010 — Главный ресторан. Если Вы хорошо знакомы с тем, как работает автоучёт модуля «Управление Запасами», Вы знаете, что наличие бухгалтерского счёта в карточке склада имеет приоритет по сравнению с таблицей автоучёта, т.е. при приходе запасов на склад 110 (в нашем примере) при создании бухгалтерской проводки дебет будет взят из карточки склада, аналогично с «уходом» — кредит в проводку по уходу с данного склада будет также взят из карточки склада. Если оставить оба поля (счёт ухода и счёт прихода) в карточке склада пустыми, будет действовать таблица автоучёта. Иными словами, любые запасы, которые попадут на склад 110, будут оприходованы как еда, независимо от того, какой учётный код указан в карточке запаса.
А теперь зададимся вопросом, зачем это было нужно. Я предполагаю, что изначально — это очень старое решение. Отдалённо оно напоминает мне также другие учётные системы с «плоским» планом счетов, когда используется не «многомерная» модель — бухгалтерский счёт и учётные измерения (как в Scala/iScala), а субсчета, как в некоторых других системах. Совсем недавно я наблюдал такой план счетов. Там каждый поставщик — это отдельный субсчёт, каждый запас — также отдельный субсчёт. Лично моё отношение к такому «плоскому» плану счетов — негативное. На мой взгляд, нет необходимости иметь счета запасов отдельно для каждого ресторана, если одновременно с этим задействовано дополнительное обязательное учётное измерение «департамент». Достаточно иметь 3 основных субсчёта запасов — Еда, Напитки, Табачные изделия (и несколько дополнительных (например, моющие средства, горючее и т.п.)) без разбивки на рестораны, эта разбивка выполняется выбором соответствующего учётного измерения «Департамент».
Второй возможный аспект (зачем это было нужно?): возможность обнуления склада. Возможно Вы читали заметку про обнуление остатков на складе, в ней говорится, в частности, что для складов, ассоциированных с кухней часто используют процедуру обнуления, тогда как для основных складов и складов с напитками, такую процедуру не используют. Если в компании используют процедуры обнуления — это явное «За» при выборе такого подхода. Если вместо процедуры обнуления производится ввод результатов инвентаризации, явной необходимости такого подхода не возникает.
Не могу не высказать своё отношение к данному подходу «в целом»: на мой взгляд, помимо вышеописанного плюса, имеются и явные минусы:
Во-первых, пользователи вынуждены при вводе требований (или заказов на закупку) разбивать одну заявку на несколько, например, отдельно на еду, отдельно на напитки, отдельно на всё остальное. Во-вторых, они часто путаются в большом количестве складов даже несмотря на явную логичность того, что запасы с кодами, начинающимися на 1 должны быть на складах, также начинающихся на 1, а запасы, начинающиеся на 2 — на складах, начинающихся также на 2. В результате возникают смешные вопросы, подобные тем, что я недавно задавал одному из бухгалтеров отеля:
- Джем — это напиток?
- Нет
- А вот и не угадал, напиток, раз он лежит на складе 210
Всё то же самое можно получить и без деления складов по принципу «Еда/Напитки/Табачные изделия» и указания в карточке склада конкретного бухгалтерского счёта. Код департамента указать нужно, а счёт — нет. Тогда и будет действовать механизм таблицы автоучёта, а он работает очень хорошо. Что касается необходимости разделения счета запасов на отдельные рестораны, я уже описал это выше.
А Вы как считаете?
