Розділ: ДаніПеріод: не вибраноЯдро 20.2.0Швидка навігація: Alt+1…6
1
Почніть із джерел
Завантажте три базові файли. Система сама підкаже наступний крок.
Очікуємо дані
Початок аудиту: завантажте джерела
Для базового аудиту потрібні три джерела: інвентаризації Майстерні, підтверджені видачі з Основного та повний Excel-експорт фізичного вибуття з keyCRM. Після завантаження система перевірить період, запропонує зіставлення назв і проведе вас до результатів. Дані та робоча памʼять зберігаються у вашому браузері.
Знайдено останню робочу сесію. Можна продовжити з того самого місця.
Локальна база ініціалізується…
Що робити на цьому кроці
1. ІнвентаризаціїЗавантажте фактичні залишки Майстерні щонайменше на дві контрольні дати.
2. ВидачіЗавантажте журнал Основний → Майстерня. Система візьме реальні денні колонки.
3. Фізичне вибуттяЗавантажте весь Excel із Google Sheets після побудови фізичного вибуття та виправлення складу рецептів.
1
Залишки Майстерні
Excel з інвентаризаціями. Потрібні назви товарів і фактичні залишки на контрольні дати до та в кінці періоду.
Матриця видач по датах. Система бере лише реальні денні колонки з позначеним днем тижня — службові/недільні колонки не сумує.
Не завантажено
Очікуваний формат: аркуш «видача».
3
Фізичне вибуття за замовленнями keyCRM
Повний Excel із нашої Google Sheets-системи. Головний аркуш — AUDIT_EXPORT; для перевірки якості потрібні також COMPONENT_LEDGER і DATA_QUALITY. Старий KGUsage лишився лише для сумісності.
Не завантажено
Завантажуйте весь Google Sheets-файл як .xlsx, а не окремий аркуш.
4
Повернення / обміни (опційно)
Журнал повернень, обмінів, списань і браку. За замовчуванням це джерело не входить у критерій повноти аудиту. Увімкни його лише для періодів, де хочеш окремо перевіряти повернення.
Опційно · вимкнено
Очікувані колонки: Товар, Причина, Дата виявлення, Вага/кількість, Дата вирішення, Коментар.
Доказове вікно
Баланс автоматично обмежується двома фактичними інвентаризаціями. Якщо кінцевий факт — 29.05, система рахує точні видачі та physical-out usage лише до 29.05; події після цього не підмішуються у баланс.
Тому окреме ручне підтвердження «після інвентаризації рухів не було» більше не потрібне.
Що означає файл продажів?
Reconstructed Usage із keyCRM прив’язаний до physical_out_at / usage_date. TTN_CREATED і FULFILLED_STATUS мають HIGH evidence; TTN_SHIPPING_DATE_FALLBACK та EMPLOYEE_PICKUP — MEDIUM. Скасовані й pending-payment замовлення не входять у usage.
Cut-off більше не визначає usage і не є автоматичним вердиктом. Він лишається тільки діагностичним сигналом на межі періоду.
Зіставлення товарів: переконайтесь, що назви означають той самий товар
Точні збіги назв система приймає автоматично. Схожі назви лише пропонує — вони не впливають на аудит, доки ти не підтвердиш відповідність. Підтвердження записується у постійний словник і надалі підтягується автоматично для цієї назви у нових імпортах. Це захищає від помилок типу «Кеш’ю 180» ↔ «Кеш’ю 320».
Як пройти цей крок
Спочатку жовтіПерегляньте позиції «Потрібне рішення». Підтверджуйте лише очевидні відповідності.
Потім червоніДля позицій без відповідності перевірте назву у джерельному файлі або довіднику.
МетаНе залишати непідтверджених позицій, які можуть впливати на баланс.
Точні збіги
—
автоматично верифіковано
Підтверджено вручну
—
збережено у словнику
Потрібне рішення
—
схожі назви, потрібне ваше рішення
Без відповідності
—
немає надійного кандидата
Назви, які потрібно перевірити
Словник: —
Джерело
Назва у файлі
Пропозиція канонічного товару
Схожість
Метод
Дія
Правило доказовостіExact match або підтверджений вручну mapping = верифіковано. Fuzzy-пропозиція без підтвердження залишається поза балансом і знижує Evidence Score.
Спочатку завантаж 3 базові джерела на вкладці «Дані». Повернення — опційно.
Режим власника. Ви самі проводите аудит, тому ручні одиниці, виключення та пояснення залишені доступними без зайвих погоджень. Первинна розбіжність при цьому завжди показується окремо.
«Сходиться»Фактичний кінцевий залишок збігається з розрахованим у межах допуску.
«Розслідувати»Є нестача або надлишок. Відкрийте товар і перевірте хронологію та підказки.
«Неповні дані»Спочатку виправте джерело, одиницю або зіставлення; висновок про нестачу ще передчасний.
Сходиться
—
товарів без суттєвого відхилення
Покриття фізичного вибуття
—
визначено / усі релевантні замовлення keyCRM
Потребують розслідування
—
розбіжність після фактичного фізичного вибуття
Неповні дані
—
бракує конкретної базової опори товару
Повністю зіставлено
—
товарів · базові 5/5
Потенційно непояснене вибуття
—
кг і шт рахуються окремо
Надлишок / неврахований вхід
—
кг і шт рахуються окремо
Середньо / робочий день
—
у своїй одиниці виміру
Видано в Майстерню
—
кг / шт окремо
Reconstructed Usage
—
прямі товари + склад рецептів
Результат по кожному товару
СходитьсяРозслідуватиНеповні даніЯкість дати вибуття
Виключені товари не беруть участі у KPI, зведенні та вердиктах.
Їх можна повернути в облік у будь-який момент. Виключення зберігається у памʼяті workspace.
0 обрано0 видимих
Товар
Од.
Старт
+ Видано
− Фізичне вибуття
= Очікували
Факт
Відхилення факт − очікувано
Сер./день
Еквівалент днів
Докази
Вердикт
Перевірка даних перед висновками
Ця вкладка відділяє «математика порахована» від «даних достатньо для аудиторського висновку».
Як читати цю сторінку
ЗеленеПеревірка пройдена або джерело достатнє для поточного розрахунку.
ЖовтеЄ обмеження. Оцініть, чи воно суттєве саме для цього аудиту.
ОрієнтирДля фізичного вибуття бажано 100% покриття, 0 невирішених замовлень і 100% покриття складу рецептів.
Історія аудиту та резервні копії
Це журнал роботи з аудитом. Тут зберігаються періоди, mapping, одиниці, кейси, налаштування та історія ключових змін. Експорт створює повну резервну копію, яку можна перенести в інший браузер або компʼютер.
Локальна памʼять
Завантаження…
Періодів0
Кейсів0
Mapping0
Подій журналу0
Рекомендація: робити резервну копію після завершення кожного місяця або великої серії розслідувань.
Збережені періоди
Журнал змін
Фіксуються імпорти джерел, mapping, кейси, одиниці, налаштування, збереження та відновлення періодів.
Методика аудиту за фізичним вибуттям
Апка використовує reconstructed usage із keyCRM по фактичній даті фізичного вибуття: physical_out_at / usage_date. Журнал видач Основний → Майстерня вважається двосторонньо підтвердженим щоденною звіркою. Cut-off не змінює баланс і не є автоматичним статусом.
1 · Баланс
Старт + Видачі − Фізичне вибуття = Очікуваний кінець (усі компоненти тільки в одній одиниці: кг або шт). Потім очікуваний кінець порівнюється з фактичною інвентаризацією.
2 · Межа періоду
Cut-off використовується лише як діагностичний сигнал. Баланс завжди рахується за фактичним usage_date; близькість розбіжності до 1–2 денних обсягів не змінює вердикт «Розслідувати».
3 · Mapping
Exact назви приймаються автоматично. Fuzzy лише пропонується і не входить у баланс, поки не підтверджено вручну.
4 · Розрив даних
Картка товару показує весь ланцюжок доказів: де є прямий факт, де лише непрямі дані, а де джерело відсутнє. Система окремо формує припущення, якого документа не вистачає.
Що ще підвищить точність
Базовий баланс уже використовує physical-out. Для доказування причин розбіжності найбільш корисні: списання/брак/карантин за датою і складом, підтверджені повернення назад на Основний та первинні документи для MEDIUM-evidence подій біля контрольної межі.