Files

AI Assistant 02689e65db fix: Исправление загрузки документов и SQL запросов

- Исправлена потеря документов при обновлении черновика (SQL объединяет вместо перезаписи)
- Исправлено определение типа документа (приоритет field_label над field_name)
- Исправлены дубликаты в documents_meta и documents_uploaded
- Добавлена передача group_index с фронтенда для правильного field_name
- Исправлены все документы в таблице clpr_claim_documents с правильными field_name
- Обновлены SQL запросы: claimsave и claimsave_final для нового флоу
- Добавлена поддержка multi-file upload для одного документа
- Исправлены дубликаты в списке загруженных документов на фронтенде

Файлы:
- SQL: SQL_CLAIMSAVE_FIXED_NEW_FLOW.sql, SQL_CLAIMSAVE_FINAL_FIXED_NEW_FLOW_WITH_UPLOADED.sql
- n8n: N8N_CODE_PROCESS_UPLOADED_FILES_FIXED.js (поддержка group_index)
- Backend: documents.py (передача group_index в n8n)
- Frontend: StepWizardPlan.tsx (передача group_index, исправление дубликатов)
- Скрипты: fix_claim_documents_field_names.py, fix_documents_meta_duplicates.py

Результат: документы больше не теряются, имеют правильные типы и field_name

2025-11-26 19:54:51 +03:00

2.8 KiB

Raw Blame History

Структура documents_meta в SQL запросах

Текущая структура после OCR объединения

После обработки файлов OCR возвращает объединённые документы со следующей структурой:

{
  "documents_meta": [
    {
      "field_name": "uploads[0][0]",
      "field_label": "Договор или заказ",
      "file_id": "clientright/0/1764167196926.pdf",
      "file_name": "1764167196926.pdf",
      "original_file_name": "1764167196926.pdf",
      "uploaded_at": "2025-11-26T14:44:51.430Z",
      "files_count": 2,    // ✅ Новое поле: сколько файлов было объединено
      "pages": 4            // ✅ Новое поле: сколько страниц в объединённом PDF
    }
  ]
}

Как SQL обрабатывает эту структуру

1. Сохранение в `clpr_claim_documents`

SQL использует jsonb_to_recordset для извлечения только нужных полей:

CROSS JOIN LATERAL jsonb_to_recordset(
  COALESCE(partial.p->'documents_meta', '[]'::jsonb)
) AS doc(
  field_name text, 
  file_id text, 
  file_name text, 
  original_file_name text, 
  uploaded_at text
)

Важно: field_label, files_count, pages не извлекаются, но это нормально - они не нужны в таблице clpr_claim_documents.

2. Сохранение в `payload->'documents_meta'`

Полный JSON сохраняется в payload через jsonb_build_object:

jsonb_build_object(
  'claim_id', partial.claim_id_str,
  'documents_meta', COALESCE(partial.p->'documents_meta', '[]'::jsonb),
  ...
)

Результат: Все поля (field_label, files_count, pages) сохраняются в payload->'documents_meta' в полном объёме.

Проверка сохранения

После выполнения SQL запроса можно проверить:

SELECT 
  payload->'documents_meta'->0->>'field_label' AS field_label,
  payload->'documents_meta'->0->>'files_count' AS files_count,
  payload->'documents_meta'->0->>'pages' AS pages
FROM clpr_claims
WHERE payload->>'claim_id' = 'bddb6815-8e17-4d54-a721-5e94382942c7';

Должны вернуться:

field_label: "Договор или заказ"
files_count: "2"
pages: "4"

Вывод

✅ SQL запрос работает правильно - дополнительные поля сохраняются в payload->'documents_meta' и доступны для использования в дальнейших операциях.

❌ Не нужно менять SQL - текущая структура достаточна для работы.

2.8 KiB Raw Blame History Unescape Escape