Облачное, но небесплатное решение - это найм рабочих пчелок, которые перелопатят прайсы и остатки, вычленив из них ту самую "уникальность" и "общность", создав те самые признаки связности.
Вторым витком - другие пчелки (более-менее владеющие предметной областью), которые все это выверят и еще добавят всяческие группирующие признаки.
Первый этап абстрактно можно возложить на нечто типа AI, но это потом немного сильнее нагрузит второй этап...
оверхеда в плане написания кода - практически 0, при желании можно делать плагины так, что они окажутся "двойного назначения" - можно положить туда, где лежат плагины, а можно запускать как exe (пользительно как минимум сделать минимальную морду например для конфигурирования и/или тестирования)
По-моему наиболее читабельный и вполне оперативный - разделить insert и update, что собственно merge с другого профиля. По крайней мере пока про insert or update - ms молчит как рыба об лед...
Вообще ноги растут из потребности иметь уникальное поле. Если нет значимого - тогда вводится искусственный "уникализатор" в виде автоинкрементного поля. Если же в таблице уже есть что-то уникальное искусственное образование большого смысла не имеет.
На сегодня с точки зрения "использования" разница весьма зыбка, ибо зачастую с-код компилируется cpp-компилятором с флагом "работать в режиме С"
Остальное - уже принципиально зависит от конкретных прикладных задач: hello world скомпилируется что на с что с++ под практически любые вычислительные устройства, а вот какая-нибудь жутко хитрая конструкция нестандартного использования железа южного моста - просто и не будет требовать компилировать на всем, а скорее даже требовать конкретную версию чипсета и т.п.
По логике C++ вырос из С и в любом случае практически везде изложение "про С++" органично подразумевает, что читатель вполне адекватно владеет С - отсюда очевиден вывод.
грубо
1. Реквизит «Признак способа расчета» (тег 1214) - 7 вариантов (предоплаты-авансы-кредиты) и среди них финишный №4
2. «Наименование предмета расчета» (тег 1030) - 12 вариантов
3. Задается фискальный тип оплат как "зачет аванса"
Там же в п.3 можно задать типы оплат типа фантиков, бонусов и т.п. но я бы это исключил и в чек гнал только цены и суммы "с учетом всех скидок и наценок" (с) инструкция ФНС
Все зависит от степени говнокодистости написания того что есть сейчас. Скорее всего после попыток украсить морду - появится навязчивое желание переделать все с нуля, что будет приземлено сроками и ценами...
Более-менее реалистичный путь - делать новые и заменять старые достаточно автономные формочки новым интерфейсом...
1. страховка
2. нормальная проводка (можно перебздеть и сделать по СНиП для пожароопасных помещений)
3. система пожаротушения
В идеале - брать жижу Novec 1230 - ей можно еще гаджеты промывать...
Правда прикидывал для серверных шкафов - если полный комплекс брать - он за 3000 баксов вылезал, но там самая дорогая часть - рэковый модуль с автоматикой
Нормальный подход:
запросить дерево в виде плоского списка (join дерева самого на себя по паренту) и к этому запросу приджойнить уже товары
конкретный запрос зависит от конкретной структуры категорий
так что как минимум надо бы привести структуру этой таблицы
(хотя почти не гадая - это id, parent_id, описание )
вначале тем или иным образом надо "классифицировать" записи по интервалам:
- через case если они константные и их немного
- через некую вспомогательную таблицу интервалов
- через "округление" дат - типа day(), month() или diff/const
т.е. в результате должна получиться таблица с колонкой interval_id - вот по нему уже и группировать
Форматирование и комментарии никто не отменял.
В совокупности с внятным именованием таблиц, их алиасов и полей - это дает возможность одним взглядом понимать что это за запрос и зачем он.
Ну и да, cte неплохо помогают не только оптимизатору, но и чтению кода.