326 lines
26 KiB
Markdown
326 lines
26 KiB
Markdown
Корпус Wave 9: 60 живых кейсов.md
|
||
|
||
Сейчас вы занимаетесь не “большим бухгалтерским ассистентом вообще”, а **доводкой P0-среза Stage 4**: ограниченный problem-first контур на трёх доменах — **60–62/банк/расчёты**, **НДС-цепочки**, **закрытие периода/затраты**. После Waves 5–8 базовый контур уже доведён до `P0_ACCEPTED_WITH_LIMITATIONS`, то есть архитектурный минимум работает, но теперь нужен **Wave 9 не про runtime, а про качество**: расширить живой корпус вопросов, усилить accountant-facing метрики и поймать скрытые quality-gap’ы — `generic_explanation_rate`, `false_confidence_rate`, `mechanism_specificity_score`, `followup_context_retention_score`, а также шумный ввод, транслит и multi-intent. Это прямо следует из playbook и Stage 1: не расширять домены, не лезть в Stage 5/6, а делать baseline stable и мерить реальную пользу бухгалтеру.
|
||
|
||
По форумной фактуре это тоже бьётся один в один: реальные вопросы крутятся вокруг **“не закрывается 60/62”, “аванс не зачёлся”, “не формируется книга покупок / не попадает счёт-фактура”, “не закрывается 20”, “остатки НЗП висят”, “68.90 не сходится с ЛК/ЕНС”**. На форумах ответы часто сводятся не к абстрактной аналитике, а к очень предметным проверкам: договор, зачёт аванса, основание счёта-фактуры, заполнение регистра, база распределения, номенклатурная группа, отчёт по расчётам/ЕНС. Это хороший сигнал для вас: корпус надо собирать не “про сущности”, а про **симптом + ожидаемое состояние + первый шаг проверки**.
|
||
|
||
Ниже даю тебе уже **готовый корпус живых человекоподобных кейсов для Wave 9**, собранный по логике форумов и под ваш продуктовый контур. Я специально делаю его не как “идеальные формулировки”, а как то, **как реально спрашивают**. Внутри каждого кейса ставлю, какую дыру он должен помогать ловить.
|
||
|
||
---
|
||
|
||
## Какой корпус вам нужен для Wave 9
|
||
|
||
Нужны не просто ещё вопросы, а вопросы, которые добивают оставшиеся quality-gap’ы:
|
||
|
||
* чтобы ассистент **не отвечал общими словами**;
|
||
* чтобы **не делал лишне уверенных выводов**;
|
||
* чтобы называл **механизм**, а не только симптом;
|
||
* чтобы **держал продолжение разговора**;
|
||
* чтобы не ломался на **шуме, разговорности, транслите и multi-intent**.
|
||
|
||
Поэтому корпус лучше строить из 4 слоёв:
|
||
|
||
1. **Core P0 symptom cases** — прямые форумные боли.
|
||
2. **Mechanism specificity cases** — где важен точный тип поломки.
|
||
3. **Follow-up cases** — продолжение без полного повторения контекста.
|
||
4. **Noisy / translit / multi-intent cases** — чтобы не было “зелёной” ложной обработки.
|
||
|
||
---
|
||
|
||
## Корпус Wave 9: 60 живых кейсов
|
||
|
||
### A. Расчёты / банк / 60–62 — 20 кейсов
|
||
|
||
1. Почему не закрываются между собой 60.01 и 60.02 по одному поставщику, суммы одинаковые, а висит и дебет, и кредит?
|
||
Теги: core, mechanism specificity
|
||
Опора: типовой форумный паттерн по 60.01/60.02.
|
||
|
||
2. Оплата поставщику прошла, акт закрыт, а 60 счёт всё равно не сворачивается. Куда смотреть первым делом?
|
||
Теги: core, actionability
|
||
Опора: частый симптом “оплата есть, закрытия нет”.
|
||
|
||
3. У меня по поставщику аванс ушёл, поступление есть, но проводки Дт 60.01 Кт 60.02 нет. Это договор или документ расчётов?
|
||
Теги: core, mechanism specificity
|
||
Опора: форумный паттерн про незачтённый аванс.
|
||
|
||
4. Почему аванс поставщику не зачёлся частично? Было 40 тысяч, акт на 20, а зачёт нужен только на 2600.
|
||
Теги: specificity, false confidence
|
||
Опора: кейсы про частичный зачёт аванса.
|
||
|
||
5. Деньги ушли в прошлом месяце, закрытие идёт в этом, и теперь расчёты разъехались. Что именно проверить по периодам?
|
||
Теги: period, mechanism specificity
|
||
|
||
6. По покупателю висит 62.01 и одновременно аванс на 62.02. Это ошибка в оплате или в закрывающем документе?
|
||
Теги: core, ambiguity
|
||
|
||
7. Несколько оплат и несколько реализаций по одному договору, а система закрыла не тем документом. Как понять, какой документ спорный?
|
||
Теги: problem-first, mechanism specificity
|
||
|
||
8. Почему после перепроведения документы по контрагенту начали закрываться по-другому, и остаток по 60 съехал?
|
||
Теги: false confidence, follow-up ready
|
||
|
||
9. Услуга закрыта, деньги заплачены, но кредиторка осталась висеть. Это точно не из-за договора “без указания документа”?
|
||
Теги: mechanism specificity
|
||
Опора: на форумах договор и документ расчётов постоянно всплывают как первый check.
|
||
|
||
10. У нас ERP, не закрывается аванс поставщику, хотя поставка пришла. Как найти разрыв: в платёжке, поступлении или зачёте?
|
||
Теги: core, actionability
|
||
Опора: серия форумных ERP-кейсов есть в собранной карте.
|
||
|
||
11. Оплата и поступление на одинаковую сумму, а свёртки нет. Что чаще всего не совпадает: договор, статья, аналитика или документ расчётов?
|
||
Теги: generic explanation trap
|
||
|
||
12. Почему после корректировки поступления зачёт аванса поехал и теперь расчёты перестали биться?
|
||
Теги: specificity
|
||
Опора: есть отдельные кейсы про корректировку поступления и зачёт аванса.
|
||
|
||
13. По одному контрагенту всё закрывается, по другому — нет, хотя схема одна и та же. Какой минимальный набор отличий нужно сравнить?
|
||
Теги: actionability
|
||
|
||
14. У меня остаток по поставщику висит копейками после серии взаимозачётов. Это признак кривой цепочки или просто округление?
|
||
Теги: false confidence
|
||
|
||
15. Почему при оплате услуг 60.02 и 60.01 не сворачиваются, если сумма одна и та же?
|
||
Теги: core
|
||
Опора: практически дословный форумный паттерн.
|
||
|
||
16. Я перепровела все документы, но 60 всё равно не закрывается. Что дальше: восстановление расчётов или искать не тот договор?
|
||
Теги: actionability
|
||
Опора: форумные ответы часто советуют договор + перепроведение/восстановление.
|
||
|
||
17. Можешь понять, это у меня реально проблема с закрытием расчётов или просто обычный незакрытый аванс, который так и должен висеть?
|
||
Теги: false confidence, limitation honesty
|
||
|
||
18. Я не понимаю, почему по поставщику в одном месте долг, а в другом переплата. Это один конфликт или две разные проблемы?
|
||
Теги: problem unit clarity
|
||
|
||
19. Скажи по-человечески, что именно сломано: деньги ушли, товар пришёл, а расчёты не закрылись.
|
||
Теги: generic explanation trap
|
||
|
||
20. У меня несколько договоров с одним поставщиком, и кажется, оплата легла не туда. Как это проверить без ковыряния всех документов подряд?
|
||
Теги: actionability, follow-up ready
|
||
|
||
---
|
||
|
||
### B. НДС / книга покупок / книга продаж — 20 кейсов
|
||
|
||
21. Почему не формируется книга покупок, если все счета-фактуры есть и проведены?
|
||
Теги: core
|
||
Опора: один из самых повторяющихся форумных симптомов.
|
||
|
||
22. Счёт-фактура есть, поступление есть, а в формирование записей книги покупок документ не попадает. Что конкретно обычно ломает цепочку?
|
||
Теги: core, mechanism specificity
|
||
Опора: типовой форумный паттерн.
|
||
|
||
23. Почему часть счетов-фактур попадает в книгу покупок, а часть нет, хотя все проведены одинаково?
|
||
Теги: ambiguity
|
||
Опора: частый симптом частичного выпадения.
|
||
|
||
24. У меня поступление и счёт-фактура на основании есть, но НДС в книге пустой. Это проблема документа-основания или регистра?
|
||
Теги: mechanism specificity
|
||
|
||
25. Не формируется проводка Дт 19 Кт 68 после корректировки поступления. Где искать конфликт?
|
||
Теги: specificity
|
||
Опора: отдельный форумный паттерн собран в карте.
|
||
|
||
26. Почему книга покупок пустая, если журнал полученных счетов-фактур заполнен?
|
||
Теги: core, false confidence
|
||
Опора: связка “журнал есть, книга пустая” встречается в практических кейсах.
|
||
|
||
27. Счет-фактура на аванс поставщику есть, галочка для книги покупок стоит, а книга всё равно пустая. Что я делаю не так?
|
||
Теги: core
|
||
Опора: форумный кейс по авансовой счёт-фактуре.
|
||
|
||
28. Документ поступления есть, счёт-фактура есть, но вычет по НДС не отразился. Это уже налоговая проблема или ещё документная?
|
||
Теги: mechanism specificity, false confidence
|
||
|
||
29. Не могу понять, почему с фильтром по счёту книга покупок не формируется, а без фильтра формируется. Это я не туда смотрю?
|
||
Теги: noisy practical case
|
||
Опора: отдельный форумный кейс по отбору по счёту.
|
||
|
||
30. Почему после ввода остатков у меня не формируется книга покупок? Это потому что счёт-фактура введена тем же числом?
|
||
Теги: period/migration
|
||
Опора: кейсы после ввода остатков есть на форуме.
|
||
|
||
31. У меня НДС “включён в стоимость”, это может объяснить, почему документ не попадает в вычет?
|
||
Теги: mechanism specificity
|
||
Опора: в предыдущем исследовании отмечалось, что форумные причины часто сидят в конкретных флагах/режимах.
|
||
|
||
32. Почему формирование записей книги покупок не берёт конкретную счёт-фактуру, хотя договор настроен на автоматическое формирование?
|
||
Теги: core
|
||
Опора: договор/настройка автоматического формирования — повторяющийся форумный мотив.
|
||
|
||
33. Мне нужен не список отчётов, а нормальный ответ: почему конкретный документ не попал в книгу покупок?
|
||
Теги: generic explanation trap
|
||
|
||
34. Это проблема периода или проблема связи “поступление → счёт-фактура”?
|
||
Теги: mechanism specificity
|
||
|
||
35. По одной организации вкладка со счётом-фактурой в поступлении есть и всё формируется, по другой — нет. Это учётная политика?
|
||
Теги: ambiguity
|
||
Опора: похожий форумный кейс с разным поведением по организациям.
|
||
|
||
36. Скажи, у меня реально разрыв НДС-цепочки или просто не хватает одного регистра/флага, чтобы это доказать?
|
||
Теги: limitation honesty
|
||
|
||
37. В книге продаж всё ок, а книга покупок пустая. Это один и тот же механизм или две разные ветки проверки?
|
||
Теги: problem unit clarity
|
||
|
||
38. После корректировки документа НДС поехал, а я не понимаю, где именно: в основании, счёт-фактуре или книге.
|
||
Теги: specificity, follow-up ready
|
||
|
||
39. У меня часть авансов по НДС берётся к вычету не так, как ожидалось. Это зачёт аванса или восстановление НДС?
|
||
Теги: ambiguity
|
||
Опора: форумный кейс по зачёту авансов и НДС.
|
||
|
||
40. Почему документ виден в одном НДС-отчёте, но не участвует в формировании записей книги покупок?
|
||
Теги: cross-branch contradiction
|
||
|
||
---
|
||
|
||
### C. Закрытие месяца / 20 / 44 / затраты — 20 кейсов
|
||
|
||
41. При закрытии месяца не закрывается 20 счёт. С чего начать, если никаких ошибок программа не показывает?
|
||
Теги: core
|
||
Опора: очень типичный форумный симптом.
|
||
|
||
42. Закрытие месяца прошло без ошибок, но остатки на 20 всё равно висят. Это норма или явный дефект?
|
||
Теги: false confidence
|
||
Опора: “прошло без ошибок, но остатки остались” — повторяющийся кейс.
|
||
|
||
43. Почему не закрывается НЗП прошлого месяца по одной номенклатурной группе, хотя выручка в периоде есть?
|
||
Теги: mechanism specificity
|
||
Опора: почти дословный форумный кейс.
|
||
|
||
44. Я руками завела расходы на 20, и после этого счёт не закрывается. Это из-за ручных операций или из-за аналитики?
|
||
Теги: specificity
|
||
Опора: форумный пример с ручными операциями Дт20 Кт71.
|
||
|
||
45. Сумма зависла на 20 счёте, но я не понимаю — это нормальное НЗП или программа не довела close до конца?
|
||
Теги: limitation honesty
|
||
Опора: на форуме прямо указывают, что часть остатков на 20 — это нормальное НЗП.
|
||
|
||
46. Почему 44 не закрывается, хотя выручка есть и вроде всё настроено?
|
||
Теги: core
|
||
Опора: кейсы по 44 есть в собранной карте форумов.
|
||
|
||
47. Документ закрытия месяца проводится, но фактического эффекта нет. Где искать: база распределения, учётная политика или аналитика затрат?
|
||
Теги: mechanism specificity
|
||
|
||
48. Выпуска нет, расходы есть. Что программа должна сделать с 20 счётом в этом случае?
|
||
Теги: false confidence
|
||
Опора: в практических материалах это отдельный типовой вопрос.
|
||
|
||
49. По одной номенклатурной группе всё закрывается, по другой — нет. Какой минимальный дифф сравнивать?
|
||
Теги: actionability
|
||
|
||
50. Почему после смены способа распределения 20 счёт стал закрываться по-другому?
|
||
Теги: follow-up ready
|
||
|
||
51. Можешь понять, что именно мешает закрытию месяца, а не просто перечислять документы по затратам?
|
||
Теги: generic explanation trap
|
||
|
||
52. Остатки на 20 висят копейками. Это rounding, НЗП или реальная поломка распределения?
|
||
Теги: false confidence
|
||
|
||
53. По идее база распределения есть, но программа ведёт себя так, как будто её нет. Куда копать?
|
||
Теги: mechanism specificity
|
||
Опора: дословно близко к форумному кейсу с “как будто нет базы распределения”.
|
||
|
||
54. После закрытия месяца по 20 всё красиво, а по 44 хвосты остались. Это одна проблема или две?
|
||
Теги: problem unit clarity
|
||
|
||
55. Закрытие затрат прошло, но себестоимость выглядит странно. Это вообще этот домен или уже другая ветка?
|
||
Теги: ambiguity
|
||
|
||
56. Я хочу понять человеческим языком: что именно сломано в закрытии — нет выпуска, нет аналитики или нет базы распределения?
|
||
Теги: generic explanation trap
|
||
|
||
57. Почему после ручной корректировки всё закрылось, а без неё нет? Это значит, что сломан маршрут закрытия?
|
||
Теги: mechanism specificity
|
||
|
||
58. У меня зависает сумма на 20 и программа молчит. Какой первый отчёт или объект смотреть, чтобы не копать всё подряд?
|
||
Теги: actionability
|
||
Опора: на форуме советуют сначала понять, что это за сумма, через профильный отчёт по затратам.
|
||
|
||
59. Это похоже на проблему периода или на проблему конкретной затратной цепочки?
|
||
Теги: mechanism specificity
|
||
|
||
60. По-человечески объясни, почему месяц “закрылся”, а результат не похож на закрытие.
|
||
Теги: accountant-facing quality
|
||
|
||
---
|
||
|
||
## Отдельный mini-pack для Wave 9: follow-up / noisy / translit / multi-intent
|
||
|
||
Эти кейсы не расширяют доменный scope, но очень нужны именно под Wave 9, потому что они бьют по `followup_context_retention_score`, `false_confidence_rate` и decomposition quality. Это прямо рекомендовано в Stage 1 и в ваших problem-first материалах.
|
||
|
||
### Follow-up
|
||
|
||
61. А теперь посмотри только по одному договору, не по всему поставщику.
|
||
62. Нет, меня интересует именно почему не зачёлся аванс, а не почему долг висит в целом.
|
||
63. Возьми тот же кейс, но только за прошлый квартал.
|
||
64. Хорошо, а если исключить корректировку, проблема всё ещё остаётся?
|
||
65. Я про тот документ, который вчера обсуждали, не про все поступления.
|
||
|
||
### Noisy / colloquial
|
||
|
||
66. Чё за фигня, бабки ушли, акт есть, а 60 всё равно висит.
|
||
67. Книга покупок пустая, хотя сч-ф все на месте, где косяк-то?
|
||
68. Месяц типа закрылся, а двадцатка как висела, так и висит.
|
||
69. По ЕНС всё вообще черт ногу сломит, с чем мне сверяться-то.
|
||
70. У меня не бьётся НДС, не надо мне список отчётов, скажи что сломано.
|
||
|
||
### Translit / mixed
|
||
|
||
71. ne zakryvaetsya 20 schet posle zakrytiya mesyatsa
|
||
72. kniga pokupok pustaya hotya schet-faktury est
|
||
73. avans postavshiku ne zaschitalsya pochemu
|
||
74. ne bietsya 68.90 s lk fns kak sverit
|
||
75. pochemu ne popadaet schet faktura v formirovanie zapisey
|
||
|
||
### Multi-intent
|
||
|
||
76. Проверь, почему не закрывается 60, и заодно скажи, не из-за этого ли не формируется книга покупок.
|
||
77. Посмотри, у меня и 20 не закрывается, и по НДС документы не попадают, это одно с другим связано?
|
||
78. Сначала пойми, почему висит 62, а потом отдельно скажи, надо ли перепроводить документы.
|
||
79. Проверь расчёты с поставщиком и скажи, не ломает ли это закрытие месяца.
|
||
80. Мне нужно понять и почему книга покупок пустая, и почему 68.90 не бьётся, но если это разные проблемы — раздели их.
|
||
|
||
---
|
||
|
||
## Как этим пользоваться в вашем контуре
|
||
|
||
Чтобы не растерять суть, я бы превращал этот корпус не просто в список вопросов, а в таблицу с такими колонками:
|
||
|
||
* `case_id`
|
||
* `domain`
|
||
* `query_text`
|
||
* `query_class`
|
||
(`symptom_first`, `lifecycle_first`, `followup`, `multi_intent`, `noisy`, `translit`)
|
||
* `expected_problem_family`
|
||
* `expected_mechanism_class`
|
||
* `must_have_first_check`
|
||
* `must_have_limitation`
|
||
* `forbidden_answer_pattern`
|
||
|
||
И вот тут у вас как раз появится нормальная связь с Wave 9:
|
||
она будет не “доделать ответы ещё чуть-чуть”, а **добить качество на тех запросах, на которых бухгалтер реально разговаривает**. Это соответствует вашему `accountant eval layer`, canonical scenario suite и benchmark logic.
|
||
|
||
## Коротко, что вы хотите от Wave 9
|
||
|
||
Если совсем сжать:
|
||
|
||
**Wave 9 нужна, чтобы доказать, что текущий P0-контур держит не только “чистые” вопросы, но и живую бухгалтерскую речь.**
|
||
|
||
То есть:
|
||
|
||
* не срывается в generic;
|
||
* не врёт уверенно;
|
||
* называет механизм;
|
||
* даёт первый шаг проверки;
|
||
* держит продолжение;
|
||
* не теряет смысл на шумном вводе.
|
||
|
||
Если хочешь, следующим сообщением я превращу это сразу в **готовую JSON/YAML-структуру для eval corpus Wave 9** с полями, чтобы это можно было почти без переделки отдать в Codex.
|