Тот же промпт вернул другую структуру: массив из одного объекта, список
поставщиков suppliers_analysis вместо suppliers_evaluation, плюсы/минусы
строкой вместо массива — и снова показывался сырой JSON. Разбор стал
терпимым: объект или массив объектов, список поставщиков — любое поле-
массив объектов с supplier, плюсы/минусы — строка или массив, плюс
recommendation.
Поток «Комментарий ИИ» стал отвечать JSON {summary, suppliers_evaluation,
conclusion} вместо текста — в шаге 3 и в SP (а значит и в PDF) лежал
сырой JSON. aiCommentToText разворачивает структуру в текст (вывод,
плюсы/минусы по поставщикам, итог) без Markdown-разметки; прежние
форматы (текст, {comment}) — как раньше. Подключено в СТ, ОИД и КПС —
при ответе потока и при чтении из SP, чтобы старые записи с JSON тоже
показывались текстом.
Когда в КП нет поля (например, сертификатов), поток отдаёт null, а
String(null) давал «null» — он показывался в «Сертификатах» шага 3 и
сохранялся в «Критерии». Разбор ответа вынесен в mapFlowResult: null —
«не распознано», как уже сделано в КПС и ОИД.
Шапку потребности старше периода собираем из позиций СТ, а вида работ
потребности там нет — подставлялся smrType позиции («ГКЛ перегородки»
вместо «СТЕНЫ И ПЕРЕГОРОДКИ»). Теперь пусто, в таблице «—».
В новой вкладке (из реестра) сессии нет, и у черновика без маршрута
степпер давал кликнуть только шаг 1 — до таблицы приходилось идти через
«Сохранить и продолжить» на каждом шаге. Теперь доступные шаги — по
данным СТ из SP: позиции → 2, КП → 3, маршрут → 4.
Шаги рендерились сразу, а СТ подгружалась позже. Шаг 1 запоминал выбор
при появлении — пустой, и при открытии из реестра показывал «Выберите
позиции», пока не обновить страницу. Теперь до загрузки — спиннер,
ошибка загрузки показывается в форме, а не только в консоли.
API /Requests/{oid}/positions отдаёт позиции без id и в разном порядке
(lineNumber — номер после сортировки по наименованию). id вида
GUID__номер указывал на разные позиции: на шаге 1 снимали одну — из СТ
удалялась другая.
Ключ — GUID потребности + хеш наименования, R66, АГСК, ед. изм.,
количества и вида СМР; одинаковые строки получают номер совпадения.
Метка h- отличает ключ от старых номерных — те ни с чем не сопоставятся.
Бэкенд extractPDFText теряет расширение у PDF с кириллицей в имени
(OCR 415 «unsupported file type ''») и отвечает 500 — КП падало при
каждой первой загрузке. Повторная загрузка «проходила» лишь потому, что
текст бэкенд успевал записать, и фронт пропускал извлечение.
Имя в библиотеке КП транслитерируется, остальные символы — в «_».
Результат детерминированный: поиск уже загруженного файла и проверка
дублей работают как раньше.
Позиции СТ из SP не были связаны с потребностями (id = SP Id), поэтому
на шаге 1 при «Выбрано: N» ни одна строка не была отмечена, «Только
выбранные» показывал пустой список, а снять выбор было негде.
- в «Позиции СТ» пишется requestPositionId (GUID потребности__номер),
шаг 1 сопоставляет выбор по нему; id позиции остаётся SP Id, к нему
привязаны предложения;
- потребности, чьи позиции уже в СТ, показываются и вне выбранного
периода (позиции догружаются сразу);
- проект восстанавливается из шапки СТ — «Сохранить и продолжить»
молча ничего не делала и снимался запрет на чужой проект.
У СТ, созданных до колонки, связи нет — их позиции в таблице не видны.
По «Сохранить и продолжить» выбранный поставщик пишется в лукап winSupplier: на шаге 4 меняется
только статус, а поставщик мог быть как обычной колонкой, так и добавленным на шаге 3.
recycle() слал POST без Content-Type с пустым odata-version — SPFx (jsonRequest) сам бросал
«requires the OData-Version header to be 3.0 or 4.0» до запроса. writeRoute общий: повторная
отправка после доработки/перезапуска ломалась во всех трёх формах; в КПС тот же recycle.
Раньше ?ctid= (ссылки потока, реестр не-черновиков) включал режим согласующего любому, кто открыл,
и режим залипал в сессии: автор СТ «На доработке» по ссылке из письма не мог править.
Теперь getCtAccess: автор правит в draft…formed и «На доработке»; согласующий и автор на
согласовании/после — просмотр с ценами на шаге 3; посторонний — просмотр без цен.
ctid/ctId равнозначны, approvalSent/isNotificationLink убраны.
Вызовы syncNoOfferSuppliers/replaceCriteria из п.3 и п.4 претензий не попали в коммиты
f5853b1 и 2b102b8 (вошли только импорты): без них согласующий и PDF не видели поставщиков
без КП и доп. поля, если шаг 2 прошли крошками.
Без активного согласующего форма отправляла потоку последнюю строку маршрута — при возврате на
доработку это мог быть следующий согласующий в статусе «Ждёт очереди», и в письме инициатору
нельзя было указать, кто вернул и с каким комментарием. Теперь (pickRowToNotify): активный
согласующий → его строка; иначе строка «На доработке» или «Отклонено»; иначе последняя.
Минимум по позиции считался, но подсветку получали только строка «Итого по позиции» у комплекта
и строки доп. расходов — обычная ячейка «Сумма, ₸» не подсвечивалась никогда, и зелёный был виден
только в общем итоге. Итог комплекта к тому же пересчитывался отдельно (без override цены в ₸ и
кол-ва позиции по умолчанию) и сравнивался строгим ===, поэтому минимум терялся на копейках.
Теперь суммы «поставщик × позиция» — один источник (sumPositionTotals), сравнение с допуском
(isMinPositionTotal), минимальная сумма зелёная в каждой позиции.
Вернуть СТ инициатору на исправление было нельзя — только «Отклонить». Теперь у согласующего
(шаг 4 и шаг 3 по ссылке из Teams) есть «На доработку» с обязательным комментарием. Строка и СТ
получают статус «На доработке», СТ сразу открыта инициатору для правки, на шаге 4 — плашка, кто
вернул и что исправить. Повторная отправка переписывает маршрут целиком — согласование с начала.
«Отклонить» с перезапуском работает как раньше.
Решение rework добавлено в общий ApproverService/DecisionPanel, но кнопка включена только в СТ ОМТС
(allowRework); в ОИД/КПС статус недостижим. В SP в Choice status «Сравнительная таблица» и
«Согласование СТ» добавлено «На доработке» (и «Отклонено» в статус СТ, которое форма уже писала).
Уведомление инициатору при доработке — в потоке Power Automate (вне репо).
КП загружались в корень библиотеки под исходным именем с перезаписью: «КП.pdf» одной СТ затирал
«КП.pdf» другой, и согласующий первой СТ открывал чужое КП. Теперь файл хранится как
«<id СТ>_<имя>» (buildKpStorageName); это имя идёт в поиск уже загруженного файла, поток, список
«Загруженные КП» и ссылку на файл. Повторная загрузка того же файла в эту же СТ по-прежнему
распознаётся.
Согласующий по ссылке из Teams попадает сразу на шаг 3, а ссылки на КП были только на шаге 2 —
открыть КП при согласовании было негде. Теперь под таблицей сравнения блок «Коммерческие
предложения» (поставщик → файл). Показывается тем же, кому видны цены: в КП тоже цены.
Участие в цепочке согласования сверялось по ФИО — при другом написании согласующему скрывались
цены (и теперь КП); сверяем по почте без учёта регистра, ФИО — запасной вариант.
Несоответствие единиц было видно только по незаметной «*» и только при включённом тумблере.
Теперь «Ед. изм.» поставщика подсвечивается жёлтым, если отличается от заявки (подсказка «В
заявке: кг, у поставщика: т»). С включённым тумблером единица, кол-во и цены подсвечиваются
голубым, если пересчитаны в ед. заявки, и красным, если пересчитать нельзя (шт ↔ кг). Статус —
чистая функция getUnitStatus; у тумблера — легенда цветов вместо «*».
Тумблер знал только массу, длину, площадь и объём в одном написании. «Штука» в заявке и «шт.»
в КП считались разными незнакомыми единицами — тумблер помечал их «пересчёт невозможен», и
казалось, что он ничего не делает. Теперь единица приводится к канонической через словарь
синонимов (шт/Штука/ед, кг/Килограмм, л/Литр, кв.м./м², пог.м/м.п. и т.д.), добавлены штучные
единицы (компл, упак, пара, рулон, лист, мешок — между собой не пересчитываются). Заодно
«кв.м.» с точкой на конце снова распознаётся: точку срезали после поиска синонимов.
Значение своей строки хранится в comment, а это в «Критерии» ОМТС многострочное поле с
форматированием: SharePoint отдаёт его как <div class="ExternalClass…">да</div>, и по ссылке
показывалась разметка. При загрузке теперь остаётся чистый текст (plainTextFromSp).
Ручные правки условий и свои строки («Добавить условие») жили только в браузере: saveCriteria
не вызывался, и согласующий, PDF и автор в новой вкладке видели лишь то, что распознал ИИ.
Теперь по «Сохранить» шага 3 «Критерии» этой СТ заменяются текущими (replaceCriteria), а при
открытии грузятся по СТ, а не по поставщику из всех СТ (loadCriteriaForCt). Свои строки
хранятся в новой колонке criteriaLabel, значение — в comment, как в ОИД.
По просьбе заказчика: «Условия оплаты» — готовые варианты (частые формулировки из SP) или свой
вариант; «Сертификаты» — Да/Нет; «Условия поставки» можно сменить и после заполнения ИИ
(раньше заполненное показывалось текстом без выбора).
Поставщиков без КП убрали из колонок (64973a2), но взамен нигде не показывали. Теперь на
шаге 3 под «Дополнительной информацией» — список «Поставщики, не предоставившие КП» с
комментарием. «Не получены КП» сохраняются с привязкой к СТ (колонка CT была в списке, но не
заполнялась, а дедуп шёл по названию на все СТ) и синхронизируются по «Сохранить» на шагах
2 и 3 — удалённые убираются; по ссылке согласующий видит список из SP. Комментарий больше
не теряется при возврате на шаг 2.
Вернулись на шаг 1 и нажали «Сохранить и продолжить» — создавалась ещё одна СТ (№10 → №11) с
теми же позициями. Предложения оставались в прежней СТ, а форма переключалась на новую,
которая по ссылке открывалась без поставщиков. Теперь, если СТ уже создана, позиции
обновляются: новые дописываются, снятые уходят в корзину вместе с их предложениями, проект
в шапке меняется при смене проекта (planStep1Save).
Заодно при возврате на шаг 1 прежний выбор виден и сохраняется: позиции нераскрытых
потребностей берутся из формы, выбранные считаются по id — раньше галочки не стояли,
«Только выбранные» был пуст, «Сохранить» неактивна.
При открытии СТ по ссылке (согласующий) или в новой вкладке предложения собирались из SP без
поля supplierPosition, и шаг 3 подставлял вместо названия из КП название позиции заявки.
Согласующий не видел, что поставщик предложил другую модель или аналог, а автор, сохранив
шаг 3 без сессии, записывал в SP название заявки поверх названия поставщика. Теперь название
читается из SP и переносится (сборка офферов вынесена в buildOffersFromSpRecords).
Окно на каждый второй КП поставщика при пакетной загрузке (6 файлов — 6 окон) было непонятно.
Теперь вопросов при загрузке нет: каждый КП — своя колонка. В «Загруженных КП» файлы одного
поставщика сгруппированы с пометкой «N КП — сравниваются отдельными колонками», а корзина
(и крестик у обработанного файла) убирает КП из сравнения — колонку, цены и записи этого
файла в SP, с подтверждением. Раньше корзина только прятала строку, колонка оставалась.
Так заменяют исправленный КП: загружают новый, старый убирают.
Заменяет окно из 744b603 (п.2).
У поставщика с несколькими КП колонки выглядели одинаково: в шапке подписывается файл КП,
в «Дополнительной информации», ИИ-комментарии и выборе рекомендованного используется имя
«Название (файл)» — ИИ сопоставляет поставщиков по имени и путал одинаковые. Adata проверяет
компанию: кэш и результат проверки получают все её колонки, «Проверить всех» делает один
платный запрос на компанию, а не на колонку.
Этап 3 из 4 (п.2).
Система не отличает исправленный КП от отдельного предложения поставщика: поставщик
определяется только по названию. Теперь, когда поток назвал поставщика, у которого в СТ уже
есть КП, обработка ждёт выбора в окне. «Заменить» — прежние колонки поставщика уходят из
сравнения, их записи в SP — в корзину (после записи нового КП, чтобы не потерять данные при
сбое). «Добавить отдельным предложением» — отдельная колонка. Закрытие окна — «добавить»:
ничего не удаляется. Несколько КП подряд — вопросы по очереди.
Этап 2 из 4 (п.2).
Колонка таблицы сравнения теперь «поставщик + файл КП» (id `${spId}_${kpFileSpId}`), а не только
поставщик. Два КП одного поставщика (напр. в KZT и USD) раньше схлопывались в одну колонку —
оставался последний файл, второе предложение пропадало. Теперь каждый КП — своя колонка со своей
валютой; записи в SP различаются по offerFileId: дедуп и чистка повторной обработки не трогают
записи другого КП того же поставщика, восстановление по ссылке раскладывает их по колонкам.
Старые колонки без файла (данные до изменения) работают как раньше.
Этап 1 из 4: выбора «заменить / добавить отдельно» пока нет — второй КП поставщика всегда
идёт отдельной колонкой.
Сборщики КПС строили поставщика, предложения и критерии по каждому файлу КП, поэтому тот же
КП под другим именем (или исправленный) давал в таблице вторую колонку того же поставщика
и задвоенные строки позиций. Теперь, как в СТ (5f5f0e7), из нескольких КП одного поставщика
берётся последний. Отбор вынесен в shared/offers/kpFiles и общий для СТ и КПС; дедуп офферов
при загрузке КПС переведён на общий keepLatestOfferRecords (поведение то же).
Заодно в репозиторий попадают тесты step2Persist.test.ts.
Шаг 2 ОИД писал предложения нового КП рядом с прежними записями поставщика. Шаг 3 всегда
грузит предложения из SP, поэтому позиция выглядела «комплектом» из одинаковых строк, а
автосохранение Шага 3 закрепляло это в SP. Теперь по повторному КП прежние записи поставщика
по тем же позициям уходят в корзину — после записи новых, чтобы при сбое не потерять данные.
Дедуп при загрузке, как в СТ, в ОИД не делаем: номер строки комплекта ОИД в Title не хранит,
и такой дедуп удалил бы настоящие строки комплекта.
Доп. строки («Логистика», «Доп. расходы») и новые поставщики шага 3 создаются в SP в начале
сохранения, а их SP-id попадали в стейт только в самом конце. Если дальше падало сохранение
офферов, id терялись, и повторное «Сохранить» создавало те же строки ещё раз. Теперь id
запоминаются сразу после создания — и при успехе, и при сбое (applyCreatedIds).
Заодно в репозиторий попадают тесты расчёта сумм matrixHelpers.test.ts.
Предложения писались внутри цикла по позициям и только если поставщика уже определил Syntex.
Syntex отключён, поставщика теперь называет поток — узнаём его после разбора всех позиций,
поэтому при обработке КП в «Оценка поставщиков» не попадало ничего: закрыл вкладку без
«Сохранить» — и разобранные цены пропали. Теперь записи строятся после определения поставщика
(buildKpOffersToSave), а сбои потока и записи идут в консоль вместо пустого catch.
Каждая обработка КП создаёт записи в «Оценка поставщиков», а прежние удалялись только
по «Сохранить». Исправленный КП поставщика или файл, загруженный заново, оставлял рядом
старые записи — отсюда дубли в SP (СТ №89, №4). Теперь после создания записи прежние
записи того же поставщика по той же позиции уходят в корзину; порядок «создать, потом
удалить» — чтобы при сбое не потерять предложение.
Повторная обработка КП добавляет в «Оценка поставщиков» новые записи, а прежние удаляются
только по «Сохранить» — в SP копились дубли (напр. СТ №89), и шаг 3 рисовал позицию
несколькими одинаковыми под-строками. Загрузчики офферов теперь оставляют одну запись
на (поставщик, позиция, itemIndex) — последнюю по Id. Загрузка по ссылке/без сессии
заодно восстанавливает itemIndex из Title: раньше все строки комплекта шли как 0.
Дедуп вынесен в shared/offers, чтобы переиспользовать в ОИД и КПС.
Они выводились на шаге 3 колонкой с нулевыми ценами, хотя сравнивать у них
нечего. Остаются в списке шага 2 и в «Не получены КП»; ручной ввод цен
сохранён за поставщиками, добавленными на самом шаге 3.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
После возврата с шага 3 очередь загрузки пуста, и КП, по умолчанию
сохранённое в тенге, нельзя было перевести в валюту без перезагрузки файла.
Теперь валюта меняется в «Загруженные КП»: обновляются supplier.currency
и пересчёт офферов в тенге; в режиме просмотра показывается код валюты.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Лукап offer в «Оценке поставщиков» смотрит на FileLeafRef библиотеки КП,
а SP не отдаёт такой лукап через REST (500), поэтому loadKpFilesForOffers
всегда возвращал пусто и «Загруженные КП» видел только автор в своей сессии.
Id файла теперь дублируется в числовое поле offerFileId и читается оттуда.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Тимур Городецкий