d-stream

Думаю стоит привести [Shablons_DopParametrs] из "человекочитаемого" в "компьютерочитаемый" вариант.
Например добавить некий тип label_type вместо того что в like и потом разово сделать

update [Shablons_DopParametrs]
set label_type = case 
          when [LABEL] LIKE '%Мобильный телефон%' then 1
          when [LABEL] LIKE '%Внутренний телефон%' then 2
          when [LABEL] LIKE '%IP-адрес текущего АРМ%' then 3
          when ....
          else null
end

а потом уже в отборах и join'ах использовать label_type

___________________________
и естественно не забыть и индекс по label_type

Провайдер выдаёт белые статические адреса по всем точкам подключения

Именно провайдер в единственном числе? Тогда стоит пообщаться с провайдером на предмет объединения сетей его возможностями. Притом это может оказаться и экономически выгодным. К примеру достаточно давно несколько площадок платили за l2vpn 100мбит/с несколько меньше чем за 10мбит/с "интернета".

Наиболее затратное по времени выполнения это расчет остатков за весь период на указанную дату в разрезе по номенклатуре.

Во-первых зачем это в crm? Во-вторых - зачем это каждый раз на заданную дату, а не на текущий момент?

Положения главы 26.5 НК РФ не запрещают индивидуальным предпринимателям совмещать несколько режимов налогообложения.

То есть не запрещают и не обязывают.

Моментиков несколько:
1. по умолчанию при регистрации ИП устанавливается ОСН (остальные - это специальные налоговые режимы). Переход на иные СНО осуществляется отдельным действием (заявление+оплата и т.п.).
2. если вдруг часть дохода "не впишется" в рамки ПСН - при отсутсвии других СНО - будет действовать ОСН

Соответственно есть резон подумать/промоделировать ситуацию в случае п.2 и оценить "потери". Вполне очевидным окажется что наименее рискованные это УСН6%+ПСН или УСН15%+ПСН. Притом в общем-то УСН6%+ПСН отличается от ПСНonly - максимум на 3 печатных листа в год. imho - совсем необременительно.

p.s. ПСН по платежам - это патент+ФФОМС+ПФР, УСН6% - это 6% - ФФОМС - ПФР[-1%ПФР от превышения 300тр]

Гм.. а в чем непонятность?
Если речь о партионном учете - т.е. в каждой продаже фигурирет отсыл на конкретную партию покупки - то собственно вычитая из отбора покупок до нужной даты отбор продаж до этой же даты через связку партий - получим остатки по каждой конкретной партии. Сумма произведений остатков в каждой партии на цену покупки - и даст сумму остатков.
Если учет по среднему - то трактовок может быть несколько:
- глобальное среднее по всем партиям прихода до нужной даты умножаем на количественный остаток (это попроще)
- закладываемся на FIFO и тогда вначале исключаем обнулившиеся "партии" (по хронологии поступления) и потом для оставшегося считаем среднее

Подразумевая MS SQL - можно воспользоваться вариантом "любой символ, но не пятерка":
типа like %555[^5]%
правда в чистом варианте стоит обыграть в начале и конце строки - то есть символа до/после не будет и "555z" или "abcde555" - не будут пойманы.

Видимо стоит подумать на тему "а что будет, если внезапно потребуется еще одну-две-двадцать-двести вывести?"

Ну и с трудом верится, что китайцы так могли накосячить...

Как-то приятель спалил hdd сходным образом. У всех первая реакция как в анекдоте про "победили сильные", но как оказалось - совсем нет. БП из именитых.

Название организации — просто "Upwork"?

Можно у них на сайте или в договорах с ними скопипастить их правильное название. Ну или из своих банковских выписок.

Я занимаюсь редактированием видео. Название товара/услуги —
"Редактирование видео"? Этого достаточно или нужно более детально?

Возможно по каждому контракту стоит опять же копировать сокращенный предмет контракта.
По крайней мере в отношениях между юл даже внутри страны платежные поручения где в назначении платежа
указывается абстрактное "оплата по счету 12345" уже давно вызывают несколько негативные реакции у банков и мониторинга. Иногда даже такие ПП возвращаются на уточнение с просьбой детализовать договор и краткую суть предмета договора.

https://dev.mysql.com/doc/refman/8.0/en/window-fun...

А зачем реальный результат (выборку) сортировать например?
Автодополнение - есть и полей и команд и при наборе и по tab (по крайней мере у SSMS старше 2008 - работает честно). Если его еще сверху приправить плагинами от redgate - вообще.

Посоветуйте что выбрать.

Выбирайте специалиста, который имеет опыт - он обоснует что надо и почем. Естественно небесплатно. Но это все в конечном итоге будет в разы дешевле самообразования в строительстве велосипедов для езды по граблям.

Эээээ

update [Contact Message In]
set Processed=1, [Received Message Date Time]=getdate()
where Processed=0

Собственно счет на оплату не нормируется КНД и прочими регламентами. Поэтому его можно формировать в произвольной форме. То бишь не надо цепляться к каким-нибудь чужим API, а тупо из своей базы формировать
- "Счет №... от ..."
- опционально перечень позиций с ценами, количествами, суммами, налогами
- сумма к оплате
- образец платежного поручения или любой другой удобный для копипастинга вариант платежных реквизитов, включая назначение платежа

ну и "офертоподобное" про то что факт оплаты означает согласие с условиями и сроками и т.п.

Можно попробовать в excel посортировать )

А вообще order by c перечислением критериев сортировки звучит именно как сортировать вначале по первому критерию внутри одинаковых - по второму и так далее...

А то что хочется - это напрашивается в качестве первого критерия - нечто синтетическое из всех трех критериев. К примеру если представить эти метрики в виде осей координат - то в качестве синтетической метрики можно использовать удаленность от начала координат - то бишь корень квадратный от суммы квадратов (в данном случае для ордеринга можно корень исключить).