Свежая статья от lsFusion с критикой 1с на Хабре

(587) А в чём проблема сделать это через виды цен? Я на самом деле не понимаю, о чём вы :((

(600) Перед записью чего ? Склада ? И в обработке менять весь регистр по всем прайсам ? Или как ?

(601) Так как через виды цен ? Есть прайс на все склады, потом создается прайс на 3 склада, потом еще на произвольных 4. Чем тут помогут виды цен ? Сколько их должно быть вообще ? Под каждый склад по виду цен или как ?

Какое-то сплошное школоло
Даже непонятно, как спорить с упоротым, что земля не плоская

(602) Зачем менять?
Ты не очень хорошо понимаешь архитектуру, я не вижу смысла дальше продолжать разговор

Споря с дураком умнее никто не станет)

(606) Поговорка, а не оскорбление, если что)

(605) Классический слив. "Ты ничего не понимаешь, а я объяснять не буду". Так слабо скинуть код ? Я готов заплатить любому 1000р за час работы по реализации точно такой же логики на 1С (как в статье). Скину на Яндекс.Деньги.

(608) Я тебе в предыдущих 4х темах объяснял много чего, но ты слышал только то что тебе выгодно. упорно игнорируято,что не выгодно.
Прости но я не работаю с неадекватами, и моя ставка выше чем 1000 в час.

(609) + 2жды переиначивал мои слова, я тебе ничего не должен и не обязан. Там я тебя раза 3 слил.
Хочешь считать что я слился - твое право

(609) Деньги - тут не главное. Могу 1500р заплатить. Я к тому, что "трындеть - не мешки тягать". А с кодом не поспоришь. Не хотите защищать свои слова - ради бога.

(611) Я вышел из того возраста когда слова анонима меня могут хоть чем то тронуть.
Кто меня знает, тот подтвердит, что я зря рот не открываю.
Но еще раз повторю, я не работаю с неадекватами.

(612) Как хотите. Возможно кто-то другой не такой принципиальный готов рассказать, как это сделать в такой постановке. Хотя сейчас, конечно, пойдет классическое как с подбором "А зачем это ?", "А это не надо" и т.д.

(613) Кстати, где маня?
Он же хотел что то там с Вами мутить

(614) И идея что то сделать с подбором тоже у него была)

(613) исходите из того, что в 1С можно реализовать любую бизнес-задачу, поэтому тут никто не хочет тратить время на примитивный пример, чтобы доказать что-то неадеквату

(616) И на ассемблере можно реализовать любую бизнес-задачу. Сколько бы у вас по времени заняло бы реализовать такой примитивный пример ?

(617) если там весь смысл в том чтоб видеть товары и склады выбранного прайс-листа то полчаса наверно )

(618) Нет. Там весь смысл, чтобы видеть действующую цену по складу с учетом всех введенных прайсов. При этом каждый прайс может иметь свой период действия (ограниченный и нет), а также распространятся на любой из уровней  группы складов (дерева динамической глубины). При изменении группы для склада (или при создании нового склада) на него, конечно же, должны автоматически распространяться все ранее созданные прайсы.

(619) Да, и цены на любую дату конечно же. Плюс должны поддерживаться "отменяющие" прайсы, когда можно на какой-то период, например, исключить товары с определенных складов.

(619) бред какой-то. Прайс он один по совокупности даты, товара и склада, что еще за "с учетом других прайсов", "отменяющие прайсы".
У вас с терминологией какая-то беда

Примерные ассоциации от очередной темы, простите:

- Покажите как в вашей системе слепить руками коника из говна - вот у нас красивые коники.
- Простите, мы 20 лет как отказались от ручной лепки, предпочитаем отливать их в формах из пластмассы.
- Ага! И сколько времени у вас займет делать форму и плавить пластмассу? Для этого ведь придется станки покупать! А у нас можно прямо руками лепить и склеивать разных коников вместе!
- Понимаете, коник из пластмассы приятнее на ощупь, в форме их можно массово отливать по несколько тысяч в день.
- Зато у нас будет дешевле, кастомно и прямо руками!

(621) Ну смотрите. Вот поставщик говорит :
1. Я готов поставлять на московский регион вот такие 10 товаров по таким ценам с 20 числа.
2. Я готов поставлять на москву вот такие 5 товаров по таким ценам с 25 числа.
3. Я не буду вам поставлять такие 3 товара на такие 3 магазина с 27 по 29 числа.

И это 3 разных управляющих воздействия (разные прайсы).

И я должен увидеть по магазину, что же готов поставщик поставлять 28 числа на конкретный магазин.

(622) ta_da, на хабре вы тоже отказались показать как этот пример сделать на 1С. Давайте не будем спорить ни о чем. Сделаете пример ? Я готов даже заплатить за час работы (и даже с предоплатой).

(623) ну фильтруем регистр "прайсов" по группе складов, конкретному магазину, дате, вычитаем исключающие по тем же условиям - получаем список товаров. Можно в один динамический список запихать на форме.
Ради этого даже базу чистую разворачивать лень

(600) О, я так тоже умею. Где бухгалтерия? Там события свойства где реализуешь, что надо. Изи.

(625) Так, стоп. Что у вас в измерениях регистра ?

(624)
вы предлагаете мне привести пример кода, который:
1) реализует невнятную логику без конкретного тз;
2) именно в той архитектуре и именно с тем подходом, который выбрали вы;
3) в идеале с таким же интерфейсом как сделано у вас;
4) с тем же количеством кода, как у вас;
чтобы что, простите?

Я потом тоже должен подобрать вариант задачи, с каким-нить drag-n-drop'ом на форме и кучей рюшечек интерфейсных, которые я могу в 1С галочкой включить, а у вас либо "не нужно пользователям", либо придется килотонны кода писать или допустим предложу вам "а давайте простенький бухучет наверните, с рашифровкой в отчетах, как бухгалтера любят", чтобы вы мне рассказали о "это задача BI", с той же уверенностью, как и когда доказывается что ваш подбор удобен?

(613) забавный ты однако, конечно ни кто не станет тратить своё время на моделирование твоих проблем

Мне фузина напомнила Парадокс для виндовс. ТАм тоже были формы, отчеты и модули, если его подрубить к ORACLE, то можно было и вызовы процедур писать.

(627) Дата1, Дата2, группаСкладов/Склад, ЭтоОтменяющий, Товар, Цена
ГруппаСкладов - иерархический справочник, ему подчинен справочник Склад. Или вообще группы убрать, просто иерархический Склад
Всё.
При выводе сортируем по Дате1 в обратку - будут показываться только цены последнего прайса, если их есть несколько по набору критериев

(623) Возникает подозрение что кто то не освоил язык запросов 1С ))
И даже про sql не слышал, которое идеально для подобных задач

(631) имхо для этого есть регистр цены поставщиков.
На каждый отдельный бизнес регион регион - отдельный партрер, который напоминаю - чисто управленческая сущность.
В рамках этой задачи - меняем понятие группы складов на принадлежность точки к бизнес региону.
Все. Задача решена.
Надо будет только запрос бахнуть, не помню есть ли типовой товары в ценах поставщиков, если есть то вообще без кода

Единственное что надо будет сделать - при смене бизнес региона менять партнёра в соответствующем месте.

И не надо никакие регистры перезаписывть

(633) оно и понятно что в УТ 11 уже это решено даже для намного более сложных случаев, человек ведь хочет с нуля на минимуме кода ))

(632) дело не в запросах

ни кому не нужный функционал учетной системы объявляется бэст-практикой и неотделимым атрибутом полноценности, пока публика не просекла, ставиться жирный плюсик в рейтинге

(635) в принципе если отчёт есть типовой то 3 строчки кода
Получаем объект
Устанавливаем новое значение партнёра
Записываем объект

(638) Связь партнера с контрагентом есть.
Бизнес регион в партнере есть из коробки.
Задача тривиальна до проще некуда

(631) Если в регистре будут группы, то как их изменять при переносе склада в другую группу ? Изменять все записи регистров ?

(637) О и так тоже я умею. Весь не нужный функционал этой УТ / ERP  объявляется бэст-практикой и неотделимым атрибутом полноценности, пока публика не просекла, ставиться жирный плюсик в рейтинге.

(640) Зачем группа складов?
В рамках этой задачи мы заменили группу складов на принадлежность подразделения бизнес региону.
По фактуэто даже с точки зрения логики правильнее, если учет зависит от территориального признака, то делитьнадо по этому признаку, а не вводить непонятнуюабстракцию

(642) Все остальные связи для решения этой задачи есть. Надо только приперемещении подразделения, или как там этот склад обосабливается,менять партнера в соответствующем месте

(631) Периодический регистр сведений или не периодический?

Что значит Группа складов/Склад? Реквизит составного типа? Запишем, потому как в 1С он через одно место реализован судя по :
https://its.1c.ru/db/metod8dev#content:1828:hdoc

С такой реализацией запросы на больших объемах положат базу чуть раньше чем сразу

(642) Причем здесь УТ ? Мы про платформу говорим, а не конфигурацию. Или вы УТ в розницу будете ставить ? И какая разница как называть группу - бизнес регионом или чем-то еще.

(645) Я просто сдеру готовые метаданные и напишу чуть чуть кода

(646) Ага, а потом будете как Google доказывать в суде присяжных Oracle'у, что это разные строчки кода :) Речь о платформе, а не о типовых конфигурациях.

(647) 1С не запрещает заимствовать код типовых конфигураций.
Если есть подписка ИТС.
А те кто не покупают подписку - я с такими не работаю.

(648) Ну так тем более, раз писать ничего не надо, то просто скиньте код, как это сделано в УТ. И я сравню со 150 строками на lsFusion и добавим в ту статью. Чтобы люди видели как это легко делается на 1С, и как сложно на lsFusion.

(648) Запрещает.

(648) Я знаю откуда содрать готовые, проверенные на оптимальность метаданные, как их воткнуть и написать как можно меньше строчек кода.

(603) Я ННП. Опишите бизнес-процесс целиком, какие склады,  как склады с ценами связаны, как вообще ценообразование работает. Пока выглядит как какой-то узкоспециализированно заточенный под какое-то предприятие процесс.

(645)[ Причем здесь УТ ? Мы про платформу говорим]
доктора в топик, срочно, ТС очень плох

открой структуру продаж 1С за прошлый год и попробуй найти там платформу

(648) То есть можно просто скопировать весь код в УТ себе в конфигурацию и ничего не платить за УТ ? И никто пока не догадался ?

(653) Так выше же товарищ кидал там стоимость 133К рублей. Это же за платформу, а не конфигурации. Разве нет ?

(650) Ну ок, я подсмотрю и сделаю очень похоже.
(649) Тык в том и суть кода то не будет.
Есть заполненный регистр цен поставщиков, где у каждого контрагента на каждый бизнес регион присутствия будет отдельный партнер.
Тебе нужен код вида
СпрОбъект = ссылка.ПолучитьОбъект();
СпрОбъект.БизнесРегион = НовыйБизнесрегион.
СпрОбъект.Записать();
Все остальное на уровне метаданных

(656) Что значит не будет кода ? Он в УТ есть ? Или там вся эта логика на уровне метаданных реализована ? То есть чисто в XML (если выгружать конфигурацию в файл) ?

(656) Ты реально понял, какой бизнес-процесс они так автоматизировали? Можешь объяснить?

(656) Ну ок не партнер, а подчиненный справочник регионыПрисутствия
регистр сведений
Изменерия:
РегионыПрисутствия
ЦенаВРегионеПрисутствия
НоменклатурПоставщика
Характеристика
ресурс
Цена
регистр периодический

(657) УТ избыточен, там слишком много задач решено.
Для решения такой простой задачи кода не надо почти

(659) А где здесь даты с которого и по которое действует ?

(661) регистр периодический - тут

(662) Соответственно надо определиться в склад пихать регион присутствия или в подразделение или куда то еще, но это уже попаболь методолога.

(662) Я не спец по 1С, в отличие от Bro.

https://its.1c.ru/db/metod8dev#content:2588:hdoc что-то я читаю вот тут про периодический регистр сведений и не вижу там даты по.

> Главное отличие периодического регистра сведений от обычного заключается в том, что в нем присутствует дополнительное системное измерение "Период", имеющее тип "дата"

А должно же быть 2 даты (по какую дату действует).

(664) Дата По я ее пропустил в начале задачи, ну пусть будет еще один реквизит, хотя это не совсем верно

(657) тяжёлый случай

1С-ники не пишут с нуля, эра нетленок умерла с 7.7.
мы живём в объектной модели типовых 1С, используя её в качестве фрэймворка

поэтому обсуждение достоинств платформы, которая нужна нам только для отладки, кроме здорового смеха ни чего не вызывает

и нам не важен объём кода в общем модуле, отвечающий за расчет и ведение скидок, большая часть которого представляет собой пакетный запрос СКД

Но если делать производительное решение, на прям хайлоад, то структура регистра будет другая
Добавится еще одно измерение - дата
И приустановке цены - на каждый день отдельная дата

(667) И регистр станетнепериодический

(665) Зачем нужна ДатаПо, чтобы определить цену на текущий момент?

(668) Это яне рассматриваю возможность "бессрочной" установки цены, а потом ее снятия, если такое потребуется, это тоже реализуемо и просто.

(669) Если у тебя датаПо меньше текущей даты, а новая цена не назначена - срез последних вернет недействтельную цену, это косяк, он тут прав.

(439) да кто бы спорил! Безусловно молодцы. Подход к маркетингу только очень совковый и по-босяцки узколобый, вызывающий брезгливое недоумение, а не желание вникнуть в суть того, в чем они там такие молодцы конкретно.

Это решение за пол часа, и оно будет более чем работоспособно на высокой нагрузке, на хайлоад - надо будет уже собирать ТЗ и аккуратно проектировать.

(671) Да ну нафиг, всегда есть базовая цена по договору поставки, перестаёт действовать спеццена - действует базовая. Я же говорю, не понятен бизнес-процесс целиком, что тут можно автоматизировать?

(673) Кстати, а какой запрос к SQL пойдет в таком случае ? Будет CTE или как, чтобы определить все группы складов из регистра, которые подходят выбранному складу ? РегионПрисутствия - это же иерархический справочник должен быть.

(671) А можно "спецу" по 1С влезть? А можно ДатаПо не в измерение, а в реквизит запихнуть и в СрезПоследних в условии использовать? У меня на учебной вроде прокатывало.

(674) Это уже частности.
Базовая цена тоже может быть не актуальна договору скажем в этом бизнес регионе и надо на экран срать ошибкой.
Но это уже вопросы к методологу.

(675) Зачем иерархия? в жопу иерархию

(676) До какого то объема можно не стесняясь, но на больших объемах я бы не стал

(678) В смысле ? Суть задачи в том, что можно цену задать на любом уровне иерархии, а также для любого склада при необходимости. Иначе это неэквивалентная задача.

(677) Эти частности показывают, что фузиновцы в бизнес-логике плавают, поэтому без точного ТЗ и подробного описания бизнес-процессов с ними смысла разговаривать нет.

(681) Да, я тоже люблю такой прием. Не хочешь чего то делать - заставь заказчика написать ТЗ, бесконечно требуя  уточнения во всех мелочах.

(680) Вы что, реально не понимаете, что описываете не реальную бизнес-задачу, а вашу практическую реализацию задачи, которая нам не известна?

(682) Никто не требует бесконечных уточнений. Просто расскажите исходную задачу, для начала, в терминах бизнеса. Начните с того, какое отношение склады имеют к ценам, и что подразумевается под складами в вашем понимании?

(680) значит условие задачи было где то там, и это тоже решается, строчек кода будет подобьше но ничего страшного.
Отловить изменение иерархии и пересчитать реквизит регион присутствия несложно.
Регистр трогать не надо

(685) я 100500 раз такое делал, вырос на ставках и тарифах, иерархия это не самое страшное, что можно придумать)

Просто да, задачу дай, под задачу надо и проектировать

По факту в общем случае - при изменении на узле в иерархии надо получить все подчиненные узлы и для них сделать что то.
Я решал такую задачу для графа (именно графа, а не дерева, которое лишь частный случай)
50 тысяч узлов пересчиталось около 2х секунд.
Время записи в базу - откидываем, это тоже решается,но это другая задача.

(688) С деревом куда как проще и быстрее

(685) Почему не надо ? Изменение иерархии чего ? Регион присутствия - это иерархический справочник должен быть. У вас в регистре что будет ? Самый нижний уровень или как ?
(683) Реальная бизнес-задача - согласование цен на поставку с поставщиком на магазины. Поставщик может давать прайсы на любое подмножество магазинов (или на любой узел группы магазинов - Московская область, регион, район) и может также делать стоп-листы. Use Case : (623)

(690) В общем случае да, расчитыватся должно для каждого конечного узла вниз по иерархии.
Как я вижу бегло - 2 сущности
Одна это разрешение поставки
Вторая это запрет поставки
Запрет поставки имеет приоритет выше чем разрешение поставки.
При внесении прайса разворачиваем до дня до конечных узлов.
При получении - отчете по узлу - объединяем с учетом приоритета

(679) Так а чем производительность будет хуже? Я просто тоже заметил, что в УТ они так не сделали, но честно говоря не могу понять почему. Запрос будет с SELECT MAX, но тот же MSSQL использует индекс по убыванию по дате и просто проверит что ДатаПо меньше заданной. Да и PostgreSQL при правильном. В любом случае не вижу разницы по сравнению с просто СрезПоследних.

(691) чисто теоретически после разузлования, можно запихнуть это в регистр расчета и наполнить кучу планов видов расчета с приоритетами, алгоритмам и методистами. Правда надо производительностью надо понаблюдать

(692) На хайлоаде я бы таки в профайлер подсмотрел,ибо иногда на практике и ожидаемое отличается

(334) "Мы как-то переводили склады с 1С на lsFusion."
если вы про "склады на 1С" имеете в виду типовые 1С-конфигурации, которые обслуживают/управляют(типа) складским товародвижением/пр - то не надо этому присваивать "склады на 1С".

"Склады на 1С" - это специализированные WMS-решения (Акселот, Топлог, Пента, Арена и прочие еще) на платформе 1С, не имеющие ничего общего с типовыми 1С-конфигурациями "для складского учета".

Детализируйте - с каких 1С-конфигураций вы "переводили" складу на фузину, интересно.

(375) "С заказчиком оговаривается фикс-прайс и дальше это не его головная боль."
-я тебя обрадую. лично как РП (+другие роли на проекте) делал алогичное на 1С (ясен пень, не на типовых конфигурациях) - фикс-прайс и делаем то что надо заказчику. а заказчик в это время занимается, как вы говорите , "бизнесом".

(446) не, Фузина все-таки продвинутей Ананаса. у Ананаса, кроме какой-то совсем мелкой хрени и деклараций чего будет - дальше не зашло. Ананас даже мельче чем 2С был. То есть Ананаса как такового - вообще нет. на нем ничего не сделано. Насколько я знаю. Фузина в этом смысле - нормальный продукт ;-)

(454) "разнообразие".. этак совсем недалеко до "толерантности", а вэто может быть чревато задом. Так что аккуратнее с посылами ;-)

Напишите ответную статью "Почему не lsfusion"

(621) Это не с терминологией.
Это прсото должно быть ТЗ/ТП на "прайсы и склады". Когда ТЗ/ТП есть - понять что про что и как реализовать - зависит от инструмента. в Фузине это каике-то группы складов могут быть. в 1С - разработанной по этой ТЗ/ТП - виду цен. Или "профили цепи поставок" или еще что-то.
.
Если фузина говорит типа "а вот у нас это уже есть модулем отдельным - 5 минут и уже готово", мы - 1Совцы - говорим, а уна - типовая конфигурация, 30 минут первоначальной настройки и есть почти все на 99% что треьбуется среднестатистической торговой компании.
.
и все.
.
пока Фузимна не выкатит готовое коробочное решение уровня хотя бы ТиС 7.7 - обсуждать - нечего. Фузина - в первую очередь платформа разработки - то есть для прогов/разработчиков. 1С - в первую очередь для потребителей - бизнесменов, манагеров, куроводятелов. Это игроки - пока - на разных полях. Достоинства/нелдостатки пусть 1С-платформы - это отражение недостатков/достоинств готовых прикладных типовых решений или наоборот.
.
нехай уже фузиновцы че-нить коробочное для массового рынка сделают, а не для 10-15 потенциальных клиентов FMCG