v7: Бух 7.7 Привязать справочник цен к контрагентам #566442


#0 by tranzit2001
Требуется в бухгалтерии сделать для каждого покупателя свои цены по для справочнка номенклатуры (прайс-лист), которые будут использоваться при отгрузке по накладной.  Таких прайсов может быть у покупателя несколько (товар от разных поставщиков). Следует хранить историю этих цен. Подскажите как организовать это?
#1 by KRV
Увольняйся.
#2 by Смотрящий от 1С
Использовать УТ 10.3
#3 by antistaks
жестоко
#4 by tranzit2001
согласен, крайний вариант думаю переподчинить типцен в справочнике цен на договоры контрагентов
#5 by Eugeneer
Все ерунда. За ваши деньги можно сделать любой каприз. бюджет какой?
#6 by Aleksey
А какая связь между поставщиком и продажной ценой? Откуда узнает чей товар вы продаете?
#7 by opty
Все равно допиливать
#8 by Темный Эльф
Че бюджет. Сначала надо узнавать годовой оборот предприятия.
#9 by Aleksey
Ну как обычно 200 рублей
#10 by Cthulhu
Вряд ли именно каждому. На самом деле оказывается нужным всего несколько категорий цен. Нужна особая - добавляйте новую категорию цены и начинайте её вести для нужной (или всей) номенклатуры. Соответственно формируйте прайсы. У любого контрика в типовой уже(!) есть реквизит "основная цена покупателя", эта категория цен уже(!) автоматически подставляется в счета и расходные. ничего допиливать не надо.
#11 by Aleksey
А как же привязка к партиям?
#12 by opty
Для каждого конкретного покупателя для каждого товара может быть своя основная цена ,  без матрицы соответствий не обойтись . Но привязывать цены к партиям это конечно что то . 1000 SKU ,предположим в среднем по 10 партий , 1000 клиентов надо хранить 10 000 000 цен Хранить самое простое , проверять , контролировать , рассчитывать плановую маржу , для каждого клиента персональный прайс ...
#13 by GreyK
Когда в бухии 7.7 партии появились?
#14 by Aleksey
Вот  я о том же, но ведь авто хочет разные цены на товар от разных поставщиков
#15 by opty
Ему без партий никак , надо разделять поставки , бухию вообще переписывать придется :) А так относительно УТ 10.3 все , и все равно надо будет дописывать
#16 by GreyK
Стена покрепче рядом есть? Чтобы, перед ней можно было разбежаться? :)
#17 by Cthulhu
: чо? : пускай заводит разные номенклатурные позиции на товар от разных поставщиков. Ж брехня.
#18 by opty
Во что превратится справочник номенклатуры через некоторое время ? Что брехня ? , по твоему в бухии партии есть ?
#19 by Cthulhu
: останется справочником номенклатуры. брехня - что партии для этого нужны.
#20 by opty
Если 50 позиций в справочнике и поставка раз в месяц можно и обойтись , если 25 000 и поставка раз в неделю миллион с четвертю элементов справочника , что тут в 16 посте советовали ?
#21 by tranzit2001
Можно обойтись без партий ведь поставщики не каждый день цены меняют. Просто у каждого поставщика свои цены. Как вариант из договора добавить кнопку на документ установки цен (придется создать), через который меняется цена в справочнике цен на дату документа и в котором можно посмотреть историю.
#22 by tranzit2001
да, позиций не много
#23 by opty
В принципе в УТ 10.3 есть понятие периодической скидки на ценовую группу , когда это исключение из ценовых политик то канает , но для системной работы с ценами нет , запутаться элементарно . Кроме того цены могут быть индикативными (жестко заданными в договоре) , и скидка может не пройти
#24 by opty
Разные цены для разных покупателей на один и тот же товар это абсолютно нормально , но цены поставщика то тут причем если товар одинаковый ? Расчет себестоимости по среднему и все . Таким путем ты назначишь только цены для номенклатурных позиций (пускай детализация партий сделана в справочнике номенклатуры) но привязку к клиенту Прикольно будет выглядеть прайс в котором пяток одинаковых позиций по разным ценам
#25 by opty
Тут только таблица соответствий (товар-клиент) с периодикой проканает , ну и достаточно капитально переписать процедуру Пересчет в доках , и прайсы.
#26 by GreyK
Напрашивается документ для ввода цен покупателю. Но не хотел-бы я за "маленькие деньги", типа "вызов", такое решать :(
#27 by Cthulhu
нихрена не надо переписывать. оптя, ты судя по всему франь?.. тут не клиент которого надо окучить, расслабься.
#28 by opty
Например некий клиент у которого тип цены по умолчанию условно первая колонка прайса , все и берет по первой колонке прайса , но ряд продуктов детского питания к примеру берет по третьей колонке
#29 by tranzit2001
ок, надо покопать в этом направлении
#30 by opty
Ну н.х франь , просто  с этой проблемой знаком как фикс каждому клиенту персональные цены , при количестве клиентов в несколько тысяч , и номенклатуры в несколько десятков тысяч . Правда до извращений зависимости цен продажи при поставке товара от разных поставщиков по разным ценам наш коммерческий отдел не додумался :)
#31 by Aleksey
Таже фигня, у нас правда не фиксированный цены для клиента хранятся, а процент наценки от базового типа
#32 by zak555
периодичность смен цен ?
#33 by tranzit2001
да, цены при смене история должна где-то храниться
#34 by opty
У нас двояко , есть скидка (хранимая , периодическая) , а есть товары с индикативными ценами , тогда приходится хранить цены Ну и естественно ценовые группы товаров , и ценовые категории клиентов , что бы все это хоть как то сгруппировать иначе пришлось бы хранить примерно 500 000 000 записей , если тупо товар к клиентам привязывать да еще с учетом периодики смены цен :)) Ну а поверх этого еще и исключения из ценовых политик (спец цены и акции)
#35 by Cthulhu
: вот как фикс, с минимальными правками и максимальным использованием типовых механизмов лично я многократно эту подобные задачи и роешал. и никаких фантастических правок типа твоих "предложений", судя по которым, а также по твоему нытью про номенклатурный справочник, ты нихрена плотно и "на результат" (с оптимумом по затратам/результату) ты не работал. или работал мало - гораздо меньше чем неплохо бы для уверенности, подобной твоей.
#36 by opty
Если товаров и клиентов не много (максимом по несколько сотен) самый простой способ (далеко не лучший) справочник Реквизит 2 - клиент Реквизит 3 - тип цены (периодический) Ну и инструментарий по заполнению и проверке , а так же очистке при необходимости свертки базы Собственно сама периодика цен хранится в ценах , в таблице только периодика соответсвий
#37 by Aleksey
Такую структуру удобно в регистре хранить
#38 by opty
Вот как пиз.обол бы лучше подсказал бы ТС как лучше товары к клиентам привязать
#39 by opty
Угу , в регистре еще удобней , несколько сложнее реализация в начале , зато потом проще и быстрее с ней работать , но у ТС бухгалтерия , какие уж там регистры
#40 by zak555
на забалансовых счетах
#41 by opty
А так сами храним на регистрах , причем структура посложней (ну и требования по ценовым политикам посложней соответственно) То же можно , но при 300 клиентах и 500 товарах (а у ТС еще и псевдопартии будут , номенклатура то раздуваться будет) и периодике смены привязки 2 раза в год это 300 000 проводок , журнал не резиновый , кроме того если потребуется узнать или рассчитать цену скажем на середину прошлого месяца , нехилые тормоза , особенности БИ
#42 by zak555
тогда регистры когда табличка будет доходить до 2 Гб, создавать новый
#43 by zak555
и т.д.
#44 by tranzit2001
спасибо за наводку
#45 by opty
Или вводить ценовые группы товара и ценовые категории клиентов , тогда количество хранимой информации сократится на несколько порядков А самое главное не парится с разными  ценами поставки разных поставщиков одного товара :) Прайсы по любому надо персонализированные делать И все это не решит проблему вывода в прайс нескольких одинаковых позиций по разным ценам , и тут уже средневзвешенная цена продажи не канает :))
#46 by zak555
офф может подскажешь по теме ?
#47 by tranzit2001
предпологается что при появлении новых цен от поставщика пользователь сам! определяет надо ли вносить  их в соответствующий прайс (изменить цены на дату прихода) Если надо он делает это вручную! (т.е. это не будет делаться  автоматом приходным документом)
#48 by opty
Нет , никогда с такой фичей не сталкивался Это то само собой , но иметь несколько разных цен в одной колонке прайса на ОДНУ и ТУ ЖЕ позицию , зависящую от того по какой цене и от какого поставщика пришел товар мягко говоря не правильно. Хотя менеджерам и не такое в голову может придти :) А почитать про особенности расчета маржи у них видимо нет желания (или способностей)
#49 by opty
Упрощенно говоря цена продажи задается из двух основных принципов (при наличии конкуренции на рынке , и отсутствии особых условий) Она должна быть достаточно низка что бы обеспечить спрос Она должна быть достаточно высока что бы обеспечить прибыль Одна граница устанавливается маркетинговыми исследованиями , другая расчетом плановой наценки . Даже при использовании партий плановая наценка считается от средней себестоимости товара (порядок расчета средней себестоимости отдельная тема) Разные цены РАЗНЫХ поставщиков не причем , есть РАЗНЫЕ цены поступления которые усредняются при расчете плана .
#50 by zak555
я считаю, что историю хранить ненадо, её можно получить усреднённую за период ДО/ДО
#51 by opty
Угу , мы строго говоря храним дату установки привязки и спец условий , этого достаточно , собственно цены хранятся штатными средствами конфигурации
#52 by opty
Или ты имел ввиду цены продажи ? Их нельзя усреднять в принципе , это же не себестоимость
#53 by tranzit2001
согласен да, альтернатива периодики - документ установки цен
#54 by zak555
кстати, да о каких ценах речь : покупателям или поставщикам ?!
#55 by opty
Документ установки цен если информация хранится на регистрах или на забалансах , при использовании справочника соответсвий периодика . При установке документом общих ценовых политик дата в регистр не пишется достаточно даты операции для получения информации , при установке документом спец-цен (акции там всякие , слив отдельных партий с выходящими сроками и пр.) в регистры пишутся дата изменения , она может и не совпадать с датой операции
#56 by zak555
+ у меня мнение, что цена для не розницы ненужна в принципе
#57 by opty
Кстати да :))) Интересно у менеджеров закзчика приказ о ценовой политике имеется утвержденный ? Или так полет фантазий
#58 by zak555
в нормальных организациях есть х +/- у =) откуда делается вывод о низах, высотах и средничке =)
#59 by tranzit2001
для покупателей не уверен
#60 by opty
Без обид , но судя по тому что оперативный учет(и работу) клиенты ведут в бухгалтерии , и по тому как тебе поставлена задача (в контексте разных цен поставки от разных поставщиков с установкой цен продажи для каждого отдельного клиента , бррр ...) это какая то шарашка :) Поковырятся конечно может быть интересно , но толку шиш Не могут разработать и упорядочить ценовые политики пусть бьют цены руками , на основании методики ППП (Пол-палец-потолок) и то косяков меньше будет
#61 by opty
Защита от "дурака" в системе привязок должна быть железобетонная Самое прикольное начнется когда по истечении определенного периода работы они захотят проверить првильность ФАКТИЧЕСКИХ цен отгрузки за какой либо период Правильно ли назначены собствено  цены согласно их типов , правильно ли типы цен привязаны к покупателю , никто не нахимичил ли там по дурости или умышленно , никто случайно задним числом не поправил в документе установки ценовых политик . Если стандартно скажем 300 товар и пять типов цен , надо проверить 1500 значений , фигня, а если 100 клиентов , то уже 150 000 комбинаций , да история смены цен продажи ... Веселуха только начинается :))
#62 by tranzit2001
да ты прав как не крути запрет на ручное изменение цен в накладной?
#63 by opty
Не поможет :( Изменили документ установки ценовых политик , перестукали накладную , цены там пересчитались , ценовые политики обратно , никаких следов . Это на вскидку Просто неправильно установили привязали цены к клиенту , по запаре , ведь таких документов как минимум несколько десятков , необходим оперативный контроль плановой наценки для клиента и т.д и т.п
#64 by opty
Просто из опыта , чем сложнее план установки цен в документе отгрузки (а в отличии от основной цены покупателя как сделано в тпиповых , персональные цены для каждого клиента достаточно сложны , а есть и еще поизвращенней) , тем больше он должен регламентироватся различными нормативными документами , инструкциями и приказами . И фундамент этого - приказ о ценовой и маркетинговой политике . Который в ряде случаев имеет право затребовать даже налоговая инспекция , наряду с приказом по учетной политике предприятия. Без разумной бюрократии потом концов не найти .
Тэги: 1С 7.7 и ранее
Ответить:
Комментарии доступны только авторизированным пользователям

В этой группе 1С