Веб-приложение для учёта возвратной тары: описываем операции оборота, залоги и потери, затем через чат создаем реестр контрагентов и отчеты по задолженности.
Возвратная тара почти всегда становится источником потерь и споров, если вести ее «по памяти». Пропадают ящики и кеги, расходятся цифры между складом и бухгалтерией, а залоги по кассе не совпадают с фактическими возвратами. Проблему обычно решает не «еще одна таблица», а учет, где фиксируются события: кто, когда и на каком основании передал или принял тару.
Ключевая мысль простая: важны не только остатки, но и движения. Остаток без истории не отвечает на вопрос, почему у клиента «минус 30 ящиков» и кто их забрал. А журнал операций показывает цепочку: отгрузили, вернули, списали, обменяли, приняли с пересортом.
Сначала договоритесь, что именно вы называете тарой. Это может быть отдельная единица (ящик, паллета, кег), комплект (упаковка по 12 бутылок) или многооборотная позиция с серийным номером (или без него). Важно, чтобы единица измерения была одинаковой для склада, продаж и бухгалтерии, иначе отчеты будут постоянно расходиться.
Хороший учет должен уверенно отвечать на четыре вопроса: у кого тара сейчас, сколько, на какую дату и почему цифра именно такая. На практике это означает, что для каждого движения должны быть понятны:
Пример: вы отгрузили магазину 40 пластиковых ящиков и взяли залог. Через неделю вернули 35, а 5 «не нашли». Если вы фиксируете только остаток, начнется переписка «мы все вернули». Если фиксируете операции, у вас есть дата, документ, ответственный и статус по залогу: что возвращено, что в задолженности, что списано по акту.
Чтобы учет не превращался в «табличку с остатками», опишите движение тары как цепочку операций. Это проще проверять, проще исправлять и легче автоматизировать. Правило одно: источником правды являются операции, а остатки считаются из них.
Начните с единицы учета. Для большинства компаний это «штуки», но иногда удобнее считать «комплектами» (ящик + крышка) или разделять по типоразмерам (например, кеги 30 л и 50 л как разные позиции). Одна позиция тары должна быть однозначной: тип, объем/размер и, при необходимости, состояние (годная/требует ремонта).
Дальше задайте минимальный набор операций, которые реально происходят в жизни. Часто хватает четырех: отгрузка контрагенту, возврат, списание и инвентаризация. Остальное можно добавить позже, когда базовая математика уже сходится.
Залог лучше учитывать отдельно от стоимости товара. Это не «цена тары», а финансовое обязательство: вы либо приняли залог, либо должны его вернуть. Поэтому у операций отгрузки и возврата часто есть денежные параметры: сумма залога, валюта/ставка и статус (взяли, не взяли, вернули, удержали). Так вы видите два независимых итога: сколько тары должны вернуть и сколько денег должны вернуть.
Потери продумайте заранее. Бой и недостача должны попадать в отдельную операцию списания, желательно с причиной и документом (например, «акт списания»). Тогда в отчете будет видно, что тара не «пропала», а выбыла по понятной причине.
Пример: водитель отвез 20 ящиков, вернул 12, еще 2 разбили в магазине. В системе это три операции, и остатки посчитаются сами. Если потом нашли еще 1 ящик на складе, это инвентаризация с комментарием, а не ручная правка остатка.
Если вы собираете такое приложение в TakProsto, удобно начинать именно с операций: в чате проще согласовать, какие поля нужны и какие отчеты должны считаться из журнала движений.
Чтобы приложение быстро давало понятные отчеты, начните с простой схемы: справочники для «кто и что», журнал операций для «что произошло», и расчетные остатки для «что должно быть сейчас».
Справочники дают единые названия и правила, чтобы в документах не было «ООО Ромашка» и «Ромашка ООО» как разных сущностей. Обычно достаточно контрагентов, точек (склады, магазины, площадки отгрузки/возврата), номенклатуры тары, договоров и условий (ставка залога, срок возврата, лимиты), а также пользователей и ролей.
Дальше все строится вокруг операций. Их можно хранить как «документы» разных типов, но с общей логикой.
Минимальный набор документов обычно покрывает большую часть реальной жизни: отгрузка, возврат, корректировка (если нашли ошибку) и списание (потери, бой, невозврат). Даже если у вас разные формы ввода, хранить данные удобно в одном журнале операций, где тип операции задается полем.
Минимальные поля для каждой операции:
Добавьте статусы, иначе отчеты будут «прыгать» из-за черновиков: черновик, проведено, отменено. В расчеты должны попадать только проведенные операции, а отмененные должны оставлять след (аудит).
Основа отчетов простая: журнал операций плюс расчетные остатки по связке контрагент + вид тары (и при необходимости точка и договор). Остатки можно считать на лету, но для скорости часто делают таблицу итогов, которая пересчитывается при проведении документа.
До разработки договоритесь о норме учета простыми словами. Один четкий абзац цели часто экономит недели переделок: что считаем (количество тары, залоги, потери), в каких разрезах (контрагент, склад, договор, вид тары) и какие 2-3 отчета нужны каждый день.
Зафиксируйте роли и ожидания. Кладовщику важен быстрый ввод операций и остатки по складу. Менеджеру - кто и сколько должен вернуть. Бухгалтеру - суммы залога и основание (какая операция и по какому договору). Руководителю - контроль потерь и динамика оборота.
Самая частая точка споров - залог. Сразу ответьте на два вопроса: когда он начисляется и когда возвращается. Например: залог начисляется при отгрузке тары контрагенту и уменьшается при возврате на склад. Потеря тары закрывает задолженность по штукам, но превращает ее в удержание залога (или в отдельный долг) - в зависимости от ваших правил. При частичном возврате тоже нужен ответ заранее: залог уменьшаем пропорционально фактически возвращенной таре или только по документу закрытия.
Теперь ограничения. Если у вас несколько складов, решите: долг по таре ведем по складу или общим итогом по контрагенту. Если несколько договоров с одним контрагентом, решите: залог и задолженность считаются раздельно по договору или можно сводить. И отдельно зафиксируйте границу: НДС и проводки не трогаем, это управленческий контур тары и залога.
Критерии готовности лучше описать сценариями, которые обязаны работать без ручных правок:
Удобнее всего идти от операций. Не начинайте с экранов и таблиц. Сначала договоритесь о смыслах: какие события бывают, что они меняют, какие проверки должны срабатывать.
Начните чат с короткого описания процесса: кто отгружает тару, кто возвращает, где фиксируется залог, бывают ли списания и пересорт. Затем попросите превратить это в операции с полями.
Перечислите 6-8 операций (например: отгрузка тары, возврат, перенос между складами, списание, корректировка, начисление залога, возврат залога) и для каждой задайте минимальные поля: дата, контрагент, документ, номенклатура тары, количество, ставка/сумма залога, комментарий.
Дальше просите генерировать приложение слоями, чтобы было что проверять руками: модели и таблицы (контрагенты, виды тары, операции, документы, остатки), экраны (список операций с фильтрами, карточка операции, справочники), правила (защита от дублей документов, обязательные поля, запрет минусовых остатков - если так принято), отчеты (задолженность по таре и по залогу, оборот за период, потери) и тестовые данные.
Чтобы запрос был понятным, можно дать шаблон:
Сгенерируй приложение: операции учета возвратной тары.
Операции: Отгрузка, Возврат, Списание, Корректировка, Начисление залога, Возврат залога.
Нужны таблицы, экраны, проверки (минусовые остатки, дубли документов), отчеты по задолженности.
Добавь тестовые данные и пример сценария на неделю.
После генерации прогоните один реальный кейс: отгрузили 50 ящиков, вернули 30, 2 потеряли, залог частично вернули деньгами. Если цифры в отчетах не сходятся, уточняйте правила и пересобирайте логику.
Если вы часто меняете формулы или операции, полезны снимки и откат: сделали правку, проверили на тестовых данных, откатили, если стало хуже.
Реестр контрагентов стоит сделать первым: почти каждая операция по таре привязана к конкретному клиенту, поставщику или перевозчику. Если справочник «плывет» из-за дублей и разного написания, отчеты по задолженности будут расходиться даже при правильных операциях.
Карточка должна быть короткой, но однозначной. Обычно хватает таких полей:
Условия лучше хранить именно как правила, а не как текст в комментарии. Тогда система сможет считать залог и просрочку автоматически.
Чтобы операции вводились быстро и одинаково, добавьте справочники точек отгрузки (магазины, РЦ), складов (ваш и контрагента) и ответственных (менеджер, кладовщик). Пример: один и тот же контрагент берет тару с двух складов, и без «точки» вы не поймете, где зависли ящики.
Перед импортом из таблицы подготовьте колонки: ИНН, название, телефон, email, контакт, ставка залога, срок возврата, точка/склад по умолчанию.
Для поиска и дублей задайте простое правило: уникальность по ИНН, а при отсутствии ИНН - предупреждение по совпадению телефона или похожему названию.
Минимальные роли доступа обычно такие: справочники правит администратор, менеджер создает контрагента, но не меняет условия залога, кладовщик только выбирает из списка.
Если операции внесены аккуратно (выдача, возврат, списание, корректировка, залог), отчеты должны собираться сами, без ручных таблиц. Иначе учет превращается в «еще одно место, где надо проверять цифры».
Базовая формула: долг по таре на дату = (всего выдано) - (всего возвращено) - (всего списано) + (корректировки, если они разрешены правилами). Считать нужно по каждому контрагенту, отдельно по складам и типам тары.
Списание - частый источник разночтений, поэтому правило важно закрепить заранее. Пример: за неделю выдали клиенту 120 ящиков, вернул 90, потери оформили актом на 10. Дальше зависит от вашей логики: списание либо закрывает обязательство по возврату (тогда долг 20), либо фиксируется отдельно и долг остается 30 до момента закрытия другим документом.
Оборот за период должен показывать три числа: выдано, возвращено, списано. По залогу важно не только «сколько денег», но и статус: начислен, получен, возвращен, удержан.
Для сверки с бухгалтерией нужен предсказуемый экспорт. Обычно хватает полей: дата операции, контрагент и договор, склад и менеджер, тип тары и количество, сумма залога и валюта.
Скорость учета решает все. Если сотруднику нужно много кликов, он начнет записывать в блокнот, а потом переносить с ошибками. Поэтому экраны стоит продумать так, чтобы основные действия занимали минуту.
Главный экран должен отвечать на вопрос: где тара сейчас и кто должен вернуть. Достаточно 3-5 цифр на сегодня (остаток у вас, выдано контрагентам, ожидается возврат, потери/списания, сумма залогов) и списка должников по таре с сортировкой по величине долга и сроку.
Быстрые действия лучше оставить короткими: новая отгрузка, новый возврат, списание/потеря, поиск контрагента, скан/ввод номера документа.
Экран операций делайте «как кассу»: один фокусный ввод, минимум полей, понятные значения по умолчанию. Обычно достаточно: дата, контрагент, тип операции, тара и количество, залог (если применяется), комментарий.
Нужны подсказки и валидации. Если по правилам «нельзя вернуть больше, чем выдано», показывайте текущий долг прямо в форме и блокируйте сохранение при превышении. Если допускаете пересорт или возврат «чужой» тары, фиксируйте это отдельной причиной, а в отчетах выводите как спорные операции.
Карточка контрагента должна быть рабочим местом: текущий долг по видам тары, история операций, лимиты (например, максимум тары на руках) и заметки. Удобно, когда из карточки можно создать возврат одним действием, а приложение само подставит контрагента.
Отдельно продумайте журнал изменений: кто исправил операцию, что было и что стало, и почему. Это спасает при разборе расхождений.
Мобильный сценарий часто критичен для приемки на месте: крупные кнопки «Возврат» и «Отгрузка», быстрый поиск по названию/телефону, возможность работать одной рукой.
Представьте поставщика напитков и сеть магазинов. Возвратная тара - кеги и пластиковые ящики. Чтобы не спорить «на словах», каждое движение фиксируется как операция: отгрузка, возврат, списание, корректировка. Залог учитывается отдельно, но привязан к тем же операциям.
День 1. Поставщик отгружает в магазин 20 кег и 40 ящиков. В учете это операция «Отгрузка» с привязкой к контрагенту и складу (или точке). Одновременно начисляется залог: например, 5000 руб за кег и 200 руб за ящик. Залог не «исчезает» в выручке, он становится обязательством вернуть деньги после возврата тары.
День 3. Магазин возвращает 15 кег. Это операция «Возврат». Осталось 5 кег, и по ним начинается вопрос: где они. После сверки выясняется, что 5 кег утеряны, и стороны подписали акт. Тогда делается операция «Списание/потери» на 5 кег с указанием причины и ответственного (магазин, перевозчик или поставщик - как договорились).
После этих шагов система должна автоматически показать:
Первая проблема начинается с номенклатуры: тару заводят как обычный товар и смешивают в одной позиции. В итоге отгрузка товара и передача тары выглядят одинаково, и потом сложно понять, что было продано, а что должно вернуться. Проще сразу разделить типы (товар, тара).
Вторая ловушка - вести только текущие остатки. Остаток без журнала операций не объясняет, где тара ушла, где вернулась, где потерялась и кто за это отвечает. При споре с контрагентом нужен не итог, а цепочка событий.
Опасная практика - разрешать минусовые остатки «чтобы не мешало работать». Иногда минус оправдан (например, возврат ввели раньше отгрузки из-за задержки документов), но тогда причина должна быть явной и контролируемой. Иначе минус превращается в тихую дыру, где ошибки маскируют друг друга.
Если у вас больше одной точки (склад, магазин, производство), не учитывайте все как один общий котел. Тара физически находится в конкретном месте. Без привязки к складу вы не сможете понять, где искать недостачу.
По залогу заранее согласуйте три вещи: когда начисляется, когда возвращается и что делаете при потерях. Пример: клиент вернул 8 ящиков из 10. Два считаются потерянными после 30 дней, залог за них удерживается или выставляется счет. Если это не закрепить, отчеты будут «правильными», но спорными.
Еще одна ошибка - слишком рано усложнять. Партии, серийные номера, десятки статусов и исключений имеют смысл только когда базовые операции уже работают.
Что стоит проверить до сборки:
Перед запуском важно проверить не «красивость» экранов, а то, что учет будет сходиться. Если система заменяет таблицы, у пользователей не должно появиться новых вопросов после первой недели.
Короткий чек перед стартом:
Дальше обычно добавляют то, что экономит время, но не меняет математику учета: экспорт для бухгалтерии, напоминания должникам, лимиты по таре на контрагента, подсказки при превышении лимита или при подозрительных списаниях.
Практичный старт - собрать первую версию в TakProsto в режиме планирования: описать операции, поля и отчеты, затем развернуть приложение и проверить на реальных кейсах. Если нужно, у TakProsto (takprosto.ai) есть экспорт исходников, а также развертывание и хостинг, чтобы довести решение до рабочего инструмента без ручных таблиц.
Начинайте с журнала операций: отгрузка, возврат, списание/потери, инвентаризация и, при необходимости, перемещение между складами. Остатки должны считаться из этих событий автоматически, иначе при споре вы не объясните, почему цифра стала такой.
Определите одну единицу учета, которую одинаково понимают склад, продажи и бухгалтерия: штука, комплект или отдельные типоразмеры (например, кег 30 л и 50 л). Если в разных отделах одна и та же тара считается по-разному, отчеты будут расходиться даже при аккуратном вводе.
Для каждой операции фиксируйте дату и время, контрагента и точку (склад/магазин), вид тары, количество, направление (выдали или приняли), основание операции и статус (черновик/проведено/отменено). Для залога добавьте сумму и понятный статус, чтобы денежные итоги не смешивались с количеством тары.
Залог лучше вести как отдельное финансовое обязательство, привязанное к операциям выдачи и возврата. Тогда вы видите одновременно две вещи: сколько тары должны вернуть и сколько денег должны вернуть, и эти цифры не путаются при частичных возвратах.
Потери оформляйте отдельной операцией списания с причиной и документом, а не «исправлением остатка». Сразу договоритесь о правиле: списание закрывает долг по штукам или остается отдельным событием до момента финансового закрытия, иначе отчеты будут правильными математически, но спорными по смыслу.
Если по правилам «нельзя вернуть больше, чем выдано», показывайте текущий долг прямо в форме и блокируйте сохранение при превышении. Если минус иногда допустим из‑за задержки документов, разрешайте его только с явной причиной и контролем, иначе минус начнет скрывать ошибки.
Долг по таре и остаток должны быть привязаны к конкретному месту, где тара находится физически, иначе вы не поймете, где искать недостачу. Даже простое поле «склад/точка» в операции обычно снимает половину вопросов при инвентаризации и сверках.
Минимально достаточно: контрагенты, точки (склады/магазины), номенклатура тары, договоры и условия залога, пользователи и роли. Ключ против дублей в контрагентах — ИНН; без него отчеты по задолженности часто ломаются из‑за разных написаний одной компании.
Опишите процесс своими словами и перечислите операции, которые реально происходят, затем попросите собрать модели, экраны, проверки и отчеты из журнала операций. В TakProsto удобнее начинать именно с операций: так проще согласовать поля и быстро прогнать реальный кейс на тестовых данных, а затем при необходимости откатиться через снимки.
Проверьте, что проходят ключевые сценарии без ручных правок: отгрузка с залогом, возврат с уменьшением долга, списание с причиной и понятным результатом по залогу, перемещение между складами без влияния на долг контрагента, сверка на дату. Дальше решайте по потребностям: на бесплатном тарифе удобно прототипировать, на платных обычно подключают развёртывание, хостинг, домен и экспорт исходников, чтобы довести учет до рабочего инструмента.