УТ. Установка цен в разрезе организаций
Добрый день всем!
В данный момент работаю с УТ 11. Встретил интересный и не понятный для себя момент: цены устанавливаются для базы в целом, без разделения по организациям. Т.е. получается неважно чей товар, на каком складе - цена в пределах вида цены не меняется.
Практический случай.
Есть организация A и филиалы B и C. У филиалов свои базы, но ценообразование ведется централизовано в базе А.
И, например, есть вид цен "Розничная". В типовом функционале я этот вид цен могу назначить только для всех организаций.
Но что если нужно чтобы на какой-либо товар у организации А розничная цена была одна, у B - другая, а у C - третья? Создавать 3 вида цен?
Видел как такое реализовано в других нетиповых конфигурациях. Есть разрез - организация. Установку цен можно произвести как для всех, так и индивидуально по организации. Соответственно, настроена миграция цен при обмене - в базу филиала выгружаются только общие цены, либо индивидуальные. Схема понятна и логична. Интересно, почему это не реализовано в УТ? Уверен этому есть объяснение, но его не нашел.
Знаю, что проблема для торговых сетей типичная, поделитесь опытом, кто сталкивался с таким и как решали?
В данный момент работаю с УТ 11. Встретил интересный и не понятный для себя момент: цены устанавливаются для базы в целом, без разделения по организациям. Т.е. получается неважно чей товар, на каком складе - цена в пределах вида цены не меняется.
Практический случай.
Есть организация A и филиалы B и C. У филиалов свои базы, но ценообразование ведется централизовано в базе А.
И, например, есть вид цен "Розничная". В типовом функционале я этот вид цен могу назначить только для всех организаций.
Но что если нужно чтобы на какой-либо товар у организации А розничная цена была одна, у B - другая, а у C - третья? Создавать 3 вида цен?
Видел как такое реализовано в других нетиповых конфигурациях. Есть разрез - организация. Установку цен можно произвести как для всех, так и индивидуально по организации. Соответственно, настроена миграция цен при обмене - в базу филиала выгружаются только общие цены, либо индивидуальные. Схема понятна и логична. Интересно, почему это не реализовано в УТ? Уверен этому есть объяснение, но его не нашел.
Знаю, что проблема для торговых сетей типичная, поделитесь опытом, кто сталкивался с таким и как решали?
По теме из базы знаний
- Многофункциональная выгрузка из 1С:УТ 11/ УТ 10 в 1С:БП2, БП3 (соответствия товаров, контрагентов, складов, статей ДДС)+Свёртка по НДС
- 1С:Управление металлургическим комбинатом 2. Модуль для 1С:ERP
- 1С:Управление строительной организацией. 1С:ERP Управление строительной организацией 2
- Программа для фулфилмента (FBS / FBO): модуль "Ответственное хранение" в 1С:УТ 11.5, КА 2.5, ERP 2.5
- ГИИС ДМДК - Управление ювелирной торговлей
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Подход с видами цен понятен. Но вот в чем минус, на мой взгляд.
Во-первых, нужно множить эти самые виды цен, т.е. будет "Розничная А", "Розничная B", "Розничная C". А если есть оптовая, ёще +3, а если есть крупнооптовая - ещё +3, и т.д. А если филиалов, не 3, а 10? Плюс потом не забывать добавлять, если сеть растет.
Затем всегда нужно учитывать, что для каждой базы свой вид цен и не ошибиться при продаже.
Плюс это всё нужно связать с обменами и прописать (по неоднозначным критериям), что мол вид цены такой-то предназначен для такой-то базы, а этот вид цен - для другой. Ну и в перспективе ошибки, неразбериха и некорректные цены.
Да и в целом просто странно. Ведь система позиционируется, как такая, в которой можно вести учет по нескольким организациям. Этот разрез есть практически во всех документах и регистрах. И тут вдруг бац - исключение. Если это фича, вот хочется понять в чем её смысл. :)
Во-первых, нужно множить эти самые виды цен, т.е. будет "Розничная А", "Розничная B", "Розничная C". А если есть оптовая, ёще +3, а если есть крупнооптовая - ещё +3, и т.д. А если филиалов, не 3, а 10? Плюс потом не забывать добавлять, если сеть растет.
Затем всегда нужно учитывать, что для каждой базы свой вид цен и не ошибиться при продаже.
Плюс это всё нужно связать с обменами и прописать (по неоднозначным критериям), что мол вид цены такой-то предназначен для такой-то базы, а этот вид цен - для другой. Ну и в перспективе ошибки, неразбериха и некорректные цены.
Да и в целом просто странно. Ведь система позиционируется, как такая, в которой можно вести учет по нескольким организациям. Этот разрез есть практически во всех документах и регистрах. И тут вдруг бац - исключение. Если это фича, вот хочется понять в чем её смысл. :)
(4)Опять таки, ситуация двоякая.
1. Цены на нескольких складах могут совпадать(те зачем множить регистр лишним измерением).
2. Для каждого магазина можно установить свой вид цен, так что проблема с обменом вообще не понятна. При этом можно один вид цен назначить нескольким магазинам.
1. Цены на нескольких складах могут совпадать(те зачем множить регистр лишним измерением).
2. Для каждого магазина можно установить свой вид цен, так что проблема с обменом вообще не понятна. При этом можно один вид цен назначить нескольким магазинам.
(4) а потом будет 10 организаций, при этом в каждой базе у каждой организации цены разные, потому что накладные расходы на логистику разные. И нужно не забывать про все организации (делать отдельный документ на каждую) при установке цен.
Это всего лишь другой подход.
Например, можно включить иерархию групп(если она не включена), создать папки и раскидать цены по папкам, чтобы пользователи меньше путались.
Это всего лишь другой подход.
Например, можно включить иерархию групп(если она не включена), создать папки и раскидать цены по папкам, чтобы пользователи меньше путались.
Благодарю за ответы. Да, согласен, это подход.
Расскажу, с чем сталкивался практически и как это было реализовано.
Например, нужно назначить по сети единую розничную цену, то для таких позиций создается один документ переоценки (с пустой организацией или с каким-то признаком "для всех"), такой документ мигрирует во все базы и фиксирует цены везде. Но есть возможность создать индивидуальную переоценку только для организации B. Для этого достаточно было выбрать организацию в документе. Например, есть территория, где у нас есть активный конкурент. Для этого региона розничная цена, скажем для 5 определенных товаров, должна быть немного ниже чем везде. Создаем переоценку для пяти товаров, указываем - только "B", проводим. Документ выгружается только в базу B. Порядок.
Здесь же придется создавать и переоценивать отдельный вид цен, который выгрузится во все базы (если не прописать сложный алгоритм фильтрации). Как-то так.
В целом решаемо конечно и не критично, но разве удобно?
Расскажу, с чем сталкивался практически и как это было реализовано.
Например, нужно назначить по сети единую розничную цену, то для таких позиций создается один документ переоценки (с пустой организацией или с каким-то признаком "для всех"), такой документ мигрирует во все базы и фиксирует цены везде. Но есть возможность создать индивидуальную переоценку только для организации B. Для этого достаточно было выбрать организацию в документе. Например, есть территория, где у нас есть активный конкурент. Для этого региона розничная цена, скажем для 5 определенных товаров, должна быть немного ниже чем везде. Создаем переоценку для пяти товаров, указываем - только "B", проводим. Документ выгружается только в базу B. Порядок.
Здесь же придется создавать и переоценивать отдельный вид цен, который выгрузится во все базы (если не прописать сложный алгоритм фильтрации). Как-то так.
В целом решаемо конечно и не критично, но разве удобно?
Виды цен в УТ11 - это аналоги прайс-листов в жизни.
Т.е. приходит к вам в конкретную фирму некий Вася и спрашивает: "А можно ваш прайс?", а вы ему выкладываете прайс листы: отдельно розничный, отдельной оптовый (при определенных закупках, безнале и предоплате). При этом выкладываете те прайс-илсты, которые действют для данного магазина и для даннноого клиента. Вот эти прайсы и есть виды цен в УТ11. Отсюда и "пляшите". Искать логику других систем в УТ11 - это такое же занятие ,как и искать логику УТ11 в дургих системах.
К примеру: "где в УТ11 оборотно-сальдовая ведомомсть? Ведь там удобно - открыл и увидел движения по всем счетам..."
или: "А где в бухгалтерии резервирование? Почему не автоматизированы закупки?"
Т.е. приходит к вам в конкретную фирму некий Вася и спрашивает: "А можно ваш прайс?", а вы ему выкладываете прайс листы: отдельно розничный, отдельной оптовый (при определенных закупках, безнале и предоплате). При этом выкладываете те прайс-илсты, которые действют для данного магазина и для даннноого клиента. Вот эти прайсы и есть виды цен в УТ11. Отсюда и "пляшите". Искать логику других систем в УТ11 - это такое же занятие ,как и искать логику УТ11 в дургих системах.
К примеру: "где в УТ11 оборотно-сальдовая ведомомсть? Ведь там удобно - открыл и увидел движения по всем счетам..."
или: "А где в бухгалтерии резервирование? Почему не автоматизированы закупки?"
Не соглашусь, с примером. Сравнивать разные области некорректно.
Мы сравниваем функционал систем для оптово-розничной торговли на базе 1С.
На мой взгляд, в ценообразовании УТ реализована логика, которая не соответствует её же собственной философии (ведение мульти-организационного учета). С таким же успехом можно создавать отдельный вида товара для каждой организации, или отдельного контрагента.
Мы сравниваем функционал систем для оптово-розничной торговли на базе 1С.
На мой взгляд, в ценообразовании УТ реализована логика, которая не соответствует её же собственной философии (ведение мульти-организационного учета). С таким же успехом можно создавать отдельный вида товара для каждой организации, или отдельного контрагента.
(10)я же описал логику: отдельный прайс лист. Тупо распечатнные листики с наименованием товаров и ценой. При чем тут организации?
Более того: ваша логика: отдельные вид товаров или отдельные окнтрагенты.
представьте себе ситуацию, когда один и тот же товар имеет различный вес для различной организации - бред? - бред.
Или один и тот же контрагент имеет разное название для разной организации. Бред? - бред!
А давайте теперь подумаем - один и тот же товар имеет РАЗНОЕ значение цены в рамках одного и того же прайса. - бред? - бред))
Более того: ваша логика: отдельные вид товаров или отдельные окнтрагенты.
представьте себе ситуацию, когда один и тот же товар имеет различный вес для различной организации - бред? - бред.
Или один и тот же контрагент имеет разное название для разной организации. Бред? - бред!
А давайте теперь подумаем - один и тот же товар имеет РАЗНОЕ значение цены в рамках одного и того же прайса. - бред? - бред))
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот