пользователям программных продуктов Scala 5.1, iScala 2.1, iScala 2.2, iScala 2.3, iScala 3.0, iScala 3.1, iScala 3.2 (и так далее)

Структура складов vs Автоучёт

Для начала «почти анекдот» на тему «чем отличается опытный консультант от неопытного»:

Неопытный консультант приходит к клиенту, смотрит на настройки системы и говорит: «Что это у Вас здесь за ерунда в настройках? Сейчас мы быстро всё исправим»
Опытный консультант приходит к клиенту, смотрит на настройки системы и говорит: «Что это у Вас здесь за ерунда в настройках? Но, раз так сделано, значит кому-то это было нужно»

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

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

  1. Кодировка запасов: коды запасов, относящиеся к еде (FOOD), начинаются на 1. Коды запасов, относящихся к напиткам, начинаются на 2, на 3 начинаются коды запасов табачных изделий, на 4 — всё остальное
  2. Внутри имеются более точное деление на группы, например, мясо, хлеб, чай и т.д.
  3. Склады также начинаются на соответствующие цифры: основной склад продуктов (еда) — 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

Всё то же самое можно получить и без деления складов по принципу «Еда/Напитки/Табачные изделия» и указания в карточке склада конкретного бухгалтерского счёта. Код департамента указать нужно, а счёт — нет. Тогда и будет действовать механизм таблицы автоучёта, а он работает очень хорошо. Что касается необходимости разделения счета запасов на отдельные рестораны, я уже описал это выше.

А Вы как считаете?

Ваше имя или псевдоним (обязательно)

Ваш e-mail (обязательно)

Тема (обязательно)

Сообщение

[recaptcha]