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