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