Решение вопросов:
1) Заказы поставщикам по конкретным заказам клиентов (связь).
2) Какие заказы клиентов размещены в заказе поставщику. Информация клиенту, что его товар заказан и информация когда поступит его заказ.
3) Какие заказы клиентов поступили на склад. Информация клиенту о поступлении товара и его привязки к резерву
4) Чьи резервы лежат на складе. Информация менеджерам и логистике.
5) Себестоимость конкретного заказа клиента, после оприходования и списания. Информация и прибыли конкретных сделок.
6) Полное отслеживание по всей истории движения.
Особенно специфично это для интернет-магазинов, где зачастую нужно конкретно знать по заказу клиента что происходит с заказом.
В управление торговлей 11 резервирование не ведется по документам, поэтому там невозможно узнать чей товар лежит на складе.
Необходимо настраивать графики поступления и тд.
Единственным механизмом получения информации является типовая обработка Состояние обеспечения заказов, что очень неудобно.
Что же делать, когда нужно конкретно для каждого заказа иметь контроль по всей цепочке.
Выход есть. Но он особенный. После долгих раздумий что делать, переписывать программу или ждать новых обновлений был найден штатный вариант, который решает задачу без серъезного вмешательства в программу.
Пользователи, которые знают программу, знают что в системе товарного учета по всем регистрам данных помимо номенклатуры есть измерение Характеристика номенклатуры. Характеристики являются частью товарного учета и движения каждой номенклатуры. Любое движение по учету с характеристикой, происходит с контролем в разрезе характеристики.
Это касается всего товарного учета целиком - заказы клиентов, поставщикам, остатки товара, себестоимость, продажи, товарные ограничения и т.д.
Тут же приведу пример: компании, работающие через интернет-магазины, знают что в системе сайта каждый заказ и даже каждая конкретная строка заказа имеет в разрезе всего сайта уникальный ID, по которому можно получить точные сведенья обо всем.
Что же в итоге. Вариант решения заключается в том, что для 1С нам нехватает такой же системы - одновременная уникальность заказа, товара и строки.
И вот что самое интересное. Чтобы реализовать в нашем случае и решить проблему нам нужно прибегнуть именно к характеристикам.
Включив учет по характеристикам мы получаем эту самую уникальность.
Если компания работает по заказной системе, нам нужно в заказе клиента завести на товары уникальные характеристики (связанные с заказом и строкой товара в заказе). Это решает всю задачу от начала до конца.
Получив в заказе на товар уникальную характеристику, мы получаем уникальную запись в учетной системе, которая будет отслеживаться по всей цепочке!
1) Делая заказы поставщикам, заполнением по заказам покупателей с характеристиками, мы получаем в заказе привязку заказов клиентов с заказами поставщикам.
2) После поступления заказа поставщика с заполненными характеристиками (уникальной записью заказа клиента) мы получаем остатки резервов в разрезе этих записей. А вот это и есть наша связка. Отчет по остаткам нам будет показывать информацию по товарам и характеристикам - это и есть расшифровка наших резервов. Получив характеристику мы легко можем получить документ заказа клиента.
Это значит что мы конкретно видим чьи резерваы лежат на складе и готовы к отгрузке.
3) Товар не зарезервируется другим покупателем, не отгрузится другому покупателю - тк при оформлении документов заказов от других клиентов, система будет требовать указать характеристику (этот жесткий контроль есть в УТ11). Сдесь не помешает добавление контроля - не позволять выбирать характеристику связанную с другим заказом и другим клиентом.
А вот сейчас вы скажете: все красиво звучит, но пользователи не будут никогда набивать характеристики. Вот тут и понадобятся небольшие вмешательства в систему, но они не будут глобальными:
1) реализация автоматической генерации характеристик. Что это? Получив в системе заказ клиента, в заказе будет только товар.
Пишем обработку через подписки на события (это не повлияет на обновления) - при проведении заказа генерировать уникальную характеристику и заполнять в заказе. (у меня в компании они генерируются автоматически при загрузке с сайта и имеют уникальный ИД с сайта, по которому мы работаем с покупателями и обменом с 1С - система выдает на сайт полную информацию о движении и состоянии заказа)
2) (тут может понадобится небольшое изменение модуля подбора). В подборе запрещаем каким либо образом выбрать характеристику другого клиента, только из свободных остатков или если под заказ - с пустой характеристикой (в момент проведения заказа она сгенерируется автоматически).
3) Через подписки добавляем к документам заказов клиентов и реализаций процедуру, которая проверяет - не выбрана ли чужая характеритиска в документ. (в момей компании мы и это не делали, тк никто руками ничего не отгружает и руками ничего не заказывает - система автоматически загружает заказы и также автоматически для склада делает отгрузки групповыми обработками)
4) в случае если компания торгует со складских запасов - необходимо будет для каждого товара генерировать характеристику - без свойств. Именно по этой характеристике будут происходить свободные продажи и резервирование из свободных остатков.
Кстати, когда я решал эту задачу с резервами вдруг внезапно выявился очень приятный побочный момент.
В УТ11 - РАУЗ. И это тоже для многих головная боль. Так вот что интересно получается, ведь РАУЗ тоже работает по номенклатуре учитывая характеристики. Т.е. средняя себестоимость не просто по товару, но с учетом характеристики. Получая уникальные записи характеристик - мы получаем систему себестоимости, которая в точности позволяет нам учитыват себестоимость в разрезе конкретных партий!
Заказ клиента -> Заказ поставщику -> Поступление товара -> Реализация (отгрузка).
При поступлении будет указана конкретная характеристика, в момент отгрузки будет выбрана конкретная уникальная характеристика - это значит, что при списании реализации будет списана себестоимость конкретной партии, т.к. себестоимость в регистре будет разделена этой аналитикой.
1) Заказы поставщикам по конкретным заказам клиентов (связь).
2) Какие заказы клиентов размещены в заказе поставщику. Информация клиенту, что его товар заказан и информация когда поступит его заказ.
3) Какие заказы клиентов поступили на склад. Информация клиенту о поступлении товара и его привязки к резерву
4) Чьи резервы лежат на складе. Информация менеджерам и логистике.
5) Себестоимость конкретного заказа клиента, после оприходования и списания. Информация и прибыли конкретных сделок.
6) Полное отслеживание по всей истории движения.
Особенно специфично это для интернет-магазинов, где зачастую нужно конкретно знать по заказу клиента что происходит с заказом.
В управление торговлей 11 резервирование не ведется по документам, поэтому там невозможно узнать чей товар лежит на складе.
Необходимо настраивать графики поступления и тд.
Единственным механизмом получения информации является типовая обработка Состояние обеспечения заказов, что очень неудобно.
Что же делать, когда нужно конкретно для каждого заказа иметь контроль по всей цепочке.
Выход есть. Но он особенный. После долгих раздумий что делать, переписывать программу или ждать новых обновлений был найден штатный вариант, который решает задачу без серъезного вмешательства в программу.
Пользователи, которые знают программу, знают что в системе товарного учета по всем регистрам данных помимо номенклатуры есть измерение Характеристика номенклатуры. Характеристики являются частью товарного учета и движения каждой номенклатуры. Любое движение по учету с характеристикой, происходит с контролем в разрезе характеристики.
Это касается всего товарного учета целиком - заказы клиентов, поставщикам, остатки товара, себестоимость, продажи, товарные ограничения и т.д.
Тут же приведу пример: компании, работающие через интернет-магазины, знают что в системе сайта каждый заказ и даже каждая конкретная строка заказа имеет в разрезе всего сайта уникальный ID, по которому можно получить точные сведенья обо всем.
Что же в итоге. Вариант решения заключается в том, что для 1С нам нехватает такой же системы - одновременная уникальность заказа, товара и строки.
И вот что самое интересное. Чтобы реализовать в нашем случае и решить проблему нам нужно прибегнуть именно к характеристикам.
Включив учет по характеристикам мы получаем эту самую уникальность.
Если компания работает по заказной системе, нам нужно в заказе клиента завести на товары уникальные характеристики (связанные с заказом и строкой товара в заказе). Это решает всю задачу от начала до конца.
Получив в заказе на товар уникальную характеристику, мы получаем уникальную запись в учетной системе, которая будет отслеживаться по всей цепочке!
1) Делая заказы поставщикам, заполнением по заказам покупателей с характеристиками, мы получаем в заказе привязку заказов клиентов с заказами поставщикам.
2) После поступления заказа поставщика с заполненными характеристиками (уникальной записью заказа клиента) мы получаем остатки резервов в разрезе этих записей. А вот это и есть наша связка. Отчет по остаткам нам будет показывать информацию по товарам и характеристикам - это и есть расшифровка наших резервов. Получив характеристику мы легко можем получить документ заказа клиента.
Это значит что мы конкретно видим чьи резерваы лежат на складе и готовы к отгрузке.
3) Товар не зарезервируется другим покупателем, не отгрузится другому покупателю - тк при оформлении документов заказов от других клиентов, система будет требовать указать характеристику (этот жесткий контроль есть в УТ11). Сдесь не помешает добавление контроля - не позволять выбирать характеристику связанную с другим заказом и другим клиентом.
А вот сейчас вы скажете: все красиво звучит, но пользователи не будут никогда набивать характеристики. Вот тут и понадобятся небольшие вмешательства в систему, но они не будут глобальными:
1) реализация автоматической генерации характеристик. Что это? Получив в системе заказ клиента, в заказе будет только товар.
Пишем обработку через подписки на события (это не повлияет на обновления) - при проведении заказа генерировать уникальную характеристику и заполнять в заказе. (у меня в компании они генерируются автоматически при загрузке с сайта и имеют уникальный ИД с сайта, по которому мы работаем с покупателями и обменом с 1С - система выдает на сайт полную информацию о движении и состоянии заказа)
2) (тут может понадобится небольшое изменение модуля подбора). В подборе запрещаем каким либо образом выбрать характеристику другого клиента, только из свободных остатков или если под заказ - с пустой характеристикой (в момент проведения заказа она сгенерируется автоматически).
3) Через подписки добавляем к документам заказов клиентов и реализаций процедуру, которая проверяет - не выбрана ли чужая характеритиска в документ. (в момей компании мы и это не делали, тк никто руками ничего не отгружает и руками ничего не заказывает - система автоматически загружает заказы и также автоматически для склада делает отгрузки групповыми обработками)
4) в случае если компания торгует со складских запасов - необходимо будет для каждого товара генерировать характеристику - без свойств. Именно по этой характеристике будут происходить свободные продажи и резервирование из свободных остатков.
Кстати, когда я решал эту задачу с резервами вдруг внезапно выявился очень приятный побочный момент.
В УТ11 - РАУЗ. И это тоже для многих головная боль. Так вот что интересно получается, ведь РАУЗ тоже работает по номенклатуре учитывая характеристики. Т.е. средняя себестоимость не просто по товару, но с учетом характеристики. Получая уникальные записи характеристик - мы получаем систему себестоимости, которая в точности позволяет нам учитыват себестоимость в разрезе конкретных партий!
Заказ клиента -> Заказ поставщику -> Поступление товара -> Реализация (отгрузка).
При поступлении будет указана конкретная характеристика, в момент отгрузки будет выбрана конкретная уникальная характеристика - это значит, что при списании реализации будет списана себестоимость конкретной партии, т.к. себестоимость в регистре будет разделена этой аналитикой.
