Я не был бы столь категоричен. Как бы то ни было, системы, допускающие отрицательные остатки вполне неплохо себя чувствуют на рынке. Я попытался привести взвешенный обзор подходов к проблеме, но утверждать, что какой-то из них однозначно хорош или плох не возьмусь.
Частичная (локальная) инвентаризация — обязательная процедура в правильно организованном бизнесе, оперирующем более чем пара тысяч наименований номенклатуры.
Но она лишь усугубляет приведенные в статье тезисы. Ибо, когда очередь дойдет до проблемной позиции, при отсутствии системного контроля за учетными остатками, менеджмент (вероятно) не сможет идентифицировать природу и(или) временнЫе моменты возникновения значительного расхождения между учетными и фактическими остатками.
Другими словами, что делать с результатами такой инвентаризации, когда известно, что учет — в глубоком дисбалансе?
Проблема в том, что обычно он не строгий: при любом расходе со склада списывается партия, которая пришла самой первой, а не та, из которой выдали. Дело в том, что если товары на складе не имеют каждый индивидального штрих-кода, кладовщик визуально не может отличить одну партию от другой.
Все так и есть. Редкие исключения (главным образом, среди аптек, оптовиков и производства) строго идентифицируют расход по серийным номерам, да и то, не по всей номенклатуре.
Есть такой кривой, но работающий способ:
Приходы и расходы заливаются одновременно в две системы
1) внутренняя система предприятия, где ГТД пофиг, но у каждого товара детально расписаны все производственные характеристики (не зависящие от партии)
2) внешняя отчётность в 1с, где фиксируются ГТД, поставщики и прочая внешняя атрибутика и делаются отгрузочные и налоговые документы. Так, что чтобы всё снаружи казалось правильно, а соответсвие партий реальным отгрузкам никто не проверяет.
Системы ведутся разными командами и практика показывает, что им даже взаимодействовать не интересно, зачем реальность тащить в «белую» бухгалтерию.
Гм. Уж очень много лишней работы.
Мы практикуем аналогичные схемы, но строго для бухгалтерского учета: весь управленческий учет в одной большой базе (но с партионным учетом и всеми атрибутами прихода, ибо их вводят операторы, отвечающие за правильный и полный ввод), а бухгалтерский учет — в отдельной базе (тоже Papyrus), которая синхронизирована с управленческой. Бухгалтерия автоматически получает в свою базу только те доки, которые ей интересны (по набору условий). То есть дублирования работы по вводу нет, бухгалтерия лишь «правильно» комбинирует уже введенные другими людьми документы.
О! Здесь вопрос часто упирается в конкретную программную систему. Если нормального партионного учета нет, то это — проблема.
При партионном учете существует только товар А, но разные партии приходят от разных поставщиков отдельными лотами. Каждый лот имеет собственную привязку к поставщику и проч (ГТД, сертификат, серийный номер и т.д.). Соответственно, остаток на складе по разным поставщикам одного товара отлично дифференцируется, а сэйлзы (и клиенты) при этом оперируют товаром как таковым, абстрагируясь о деталей.
Честно сказать, для меня загадка, как вендоры систем, в которых перечисленные выше атрибуты ассоциируются непосредственно с товаром, разруливают жалобы клиентов на необходимость каждый раз заводить новую карточку одного и того же товара. Было бы интересно почитать.
Насчет «порекомендуете»: при существовании, указанного мной выше, отсутствии партионного учета заводить отдельный А для отображения в него А1 и А2 — излишество. Надо придумывать программные (или какие-то иные) способы унификации А1 и А2.
Уникальность товаров обеспечивается через уникальность штрихкодов и наименований. Для дублей, которые умудряются обойти эти ограничения, есть несколько техник подстановки:
— описанная в статье подстановка дефицитного товара
— автоматическая подстановка по заранее определенным схемам. То есть, может быть определен набор взаимозаменяемых товаров (с приоритетами и пропорциями подстановки).
Тяжелее всего проблема дублирования — в контексте синхронизации между удаленными разделами базы данных, но там она решается хитрым техническим трюком — таблицей синхронизации. Думая расписать популярно эту технологию позже.
Да, забыл. Есть функция объединения объектов с переносом ссылок с одного на другой. Скажем, товары A1 и A2 — фактически идентичны. Тогда можно объединить A1 с A2 таким образом, что все ссылки с A2 будут переброшены на A1, и A2 будет удален. Функция простая и быстрая для пользователя (реализовывалась, правда, долго и мучительно).
Так это ж врожденная проблема ERP-систем — дефицит пространства в форме. По-просту говоря, обычно такую важную подсказку некуда впихнуть.
Насчет первичности «процессов на предприятии» полностью согласен: никакое программное решение не заменит правильную организацию бизнеса.
Но она лишь усугубляет приведенные в статье тезисы. Ибо, когда очередь дойдет до проблемной позиции, при отсутствии системного контроля за учетными остатками, менеджмент (вероятно) не сможет идентифицировать природу и(или) временнЫе моменты возникновения значительного расхождения между учетными и фактическими остатками.
Другими словами, что делать с результатами такой инвентаризации, когда известно, что учет — в глубоком дисбалансе?
Все так и есть. Редкие исключения (главным образом, среди аптек, оптовиков и производства) строго идентифицируют расход по серийным номерам, да и то, не по всей номенклатуре.
Гм. Уж очень много лишней работы.
Мы практикуем аналогичные схемы, но строго для бухгалтерского учета: весь управленческий учет в одной большой базе (но с партионным учетом и всеми атрибутами прихода, ибо их вводят операторы, отвечающие за правильный и полный ввод), а бухгалтерский учет — в отдельной базе (тоже Papyrus), которая синхронизирована с управленческой. Бухгалтерия автоматически получает в свою базу только те доки, которые ей интересны (по набору условий). То есть дублирования работы по вводу нет, бухгалтерия лишь «правильно» комбинирует уже введенные другими людьми документы.
При партионном учете существует только товар А, но разные партии приходят от разных поставщиков отдельными лотами. Каждый лот имеет собственную привязку к поставщику и проч (ГТД, сертификат, серийный номер и т.д.). Соответственно, остаток на складе по разным поставщикам одного товара отлично дифференцируется, а сэйлзы (и клиенты) при этом оперируют товаром как таковым, абстрагируясь о деталей.
Честно сказать, для меня загадка, как вендоры систем, в которых перечисленные выше атрибуты ассоциируются непосредственно с товаром, разруливают жалобы клиентов на необходимость каждый раз заводить новую карточку одного и того же товара. Было бы интересно почитать.
Насчет «порекомендуете»: при существовании, указанного мной выше, отсутствии партионного учета заводить отдельный А для отображения в него А1 и А2 — излишество. Надо придумывать программные (или какие-то иные) способы унификации А1 и А2.
— описанная в статье подстановка дефицитного товара
— автоматическая подстановка по заранее определенным схемам. То есть, может быть определен набор взаимозаменяемых товаров (с приоритетами и пропорциями подстановки).
Тяжелее всего проблема дублирования — в контексте синхронизации между удаленными разделами базы данных, но там она решается хитрым техническим трюком — таблицей синхронизации. Думая расписать популярно эту технологию позже.
Да, забыл. Есть функция объединения объектов с переносом ссылок с одного на другой. Скажем, товары A1 и A2 — фактически идентичны. Тогда можно объединить A1 с A2 таким образом, что все ссылки с A2 будут переброшены на A1, и A2 будет удален. Функция простая и быстрая для пользователя (реализовывалась, правда, долго и мучительно).