Система обліку передачі допомоги корисна тоді, коли дозволяє встановити, що саме було передано і що підтвердив отримувач. Один прапорець «доставлено» часто приховує кілька різних подій: виїзд зі складу, прибуття транспорту, перевірку кількості та прийом матеріалів відповідальною людиною. Для робочого обліку ці події потрібно розрізняти.
У вигаданому прикладі районний громадський центр передає сусідній бібліотеці коробки канцтоварів. Система описує рух матеріалів і підтвердження сторін; вона не визначає право людини на допомогу й не вирішує, кому її розподіляти. Бібліотека отримує менше зошитів, ніж зазначено у відправленні. Саме порядок фіксації такої різниці визначає надійність обліку.
Визначте одиницю передачі та незмінний номер
Операція повинна мати власний ідентифікатор, перелік позицій, одиниці виміру та відповідальних з обох сторін. Коробка і штука не взаємозамінні без явного коефіцієнта. Якщо склад рахує упаковки, а отримувач окремі предмети, узгодьте представлення до першого експорту. Збережіть також версію опису товару, використану під час відправлення.
Повторне натискання підтвердження не повинно повторно списувати матеріали. Сервер має розпізнавати повтор операції та повертати її актуальний результат. Проте дві різні передачі однакового складу не можна автоматично об’єднувати лише через схожість кількості й дати. Для зв’язку потрібен номер реальної операції, а не приблизний пошук.
Отримання підтверджує інша подія
Відправник фіксує фактично передані позиції. Отримувач підтверджує фактично прийняті та позначає розбіжність, якщо вона є. До узгодження обидва значення мають бути видимі. Система повинна пояснювати, хто зараз розглядає різницю і яка дія потрібна, не перезаписуючи початкову заяву однієї сторони словами іншої.
Фото накладної може бути вкладенням, але саме по собі не доводить прийом усіх позицій. Завантаження файлу має окремий стан, і його збій не повинен стирати вже введені кількості. Для підписів або додаткових підтверджень сторони визначають потрібний процес окремо; наявність кнопки в застосунку не створює автоматично юридичної сили документа.
Виправлення додавайте, а не приховуйте
Якщо після прийому виявили помилку в кількості, збережіть попередній запис і додайте коригування з причиною, автором та часом. Пов’яжіть його з конкретною передачею й позицією. Підсумковий залишок може враховувати корекцію, але звіт має дозволяти відновити послідовність, за якою команда отримала поточне число.
Визначте, хто може створити коригування і хто його погоджує. За одночасної роботи двох операторів перевіряйте актуальну версію запису. Не дозволяйте непомітно двічі врахувати одну розбіжність. Для скасування помилкового коригування потрібен такий самий зрозумілий слід, а не приховане редагування бази адміністратором без пояснення.
Зіставте операцію, залишок і експорт
Приймальний тест має включати часткове отримання, відкладене завантаження фото, повтор підтвердження та виправлення наступного дня. Після кожного кроку порівняйте журнал операції, складський залишок і файл звіту. Перевірте, чи людина без відповідного доступу не бачить контакти отримувача через пряме посилання на вкладення або експорт.
Окремо погодьте мінімальний набір персональних даних і строк їх збереження відповідно до вашого процесу. Brainbaby Labs може допомогти створити вебінструмент для такого операційного обліку. Для оцінки підготуйте знеособлений приклад передачі, типову розбіжність і бажаний звіт: це дає змогу перевірити модель до появи великої кількості записів.