Учет товаров в 1С УНФ: как не потерять коробки, цвета и остатки, которые вроде бы есть, а вроде бы и нет
Привет, я СБиСик. И сегодня разберем тему, на которой у многих бизнесов, честно говоря, спотыкается весь учет. Снаружи все выглядит просто: товар пришел, товар продался, остаток где-то должен быть. А потом открываешь 1С УНФ — и начинается эта знакомая история: на складе по программе одно, на полке другое, в коробках третье, а в голове вообще четвертое.
Вот почему учет товаров в 1С УНФ — это не про «вбили накладную и забыли». Это про систему, которая должна понимать, что у вас есть коробка, в коробке 20 килограммов, часть продали на развес, часть уехала в магазин, а еще это все бывает в черном, белом и, как назло, в размере M, который закончился вчера. Если это не настроить сразу, потом остатки начинают жить своей жизнью. И да, это обычно замечают уже в самый неудобный момент — когда нужен отчет, закрытие месяца или срочно надо понять, куда делся товар.
Я такие истории вижу регулярно. Кто-то раньше работал только в кассовой программе, где товар — это просто строка. Потом бизнес подрос, появились склады, упаковки, разные поставщики, производство, розница, и старая схема уже не тянет. УНФ как раз и берут, чтобы навести порядок. Но тут есть нюанс: программа умеет многое, только вот включать эти возможности надо руками. Иначе получается не учет, а имитация учета.
Кстати, короткие наблюдения из таких кейсов я иногда выкладываю быстрее в наш канал в MAX, потому что пока соберешь все примеры в одну большую статью, у клиента уже успевает возникнуть новый вопрос. Жизнь вообще шустрая штука, особенно когда речь о складe и остатках.
С чего начинается нормальный учет: не с накладной, а с настройки
Самая частая ошибка — думать, что учет товаров в 1С УНФ начинается с документа поступления. Нет, не с него. Сначала надо понять, как именно вы хотите считать товар. В штуках? В килограммах? В коробках? По цветам? По складам? По ячейкам? Потому что если это не определить на старте, потом система честно начнет путаться вместе с вами.
Первое, что обычно смотрю в базе, — это раздел «Настройки» → «Еще больше возможностей». Там включаются вещи, которые потом сильно влияют на весь учет. Например, для складского движения важны параметры учета запасов, а если бизнесу нужно разделение по цветам, размерам или моделям, то без включенных характеристик далеко не уедешь. Да и производство без специального переключателя в УНФ просто не появится как нормальный сценарий, а это отдельная история.
И вот тут, кстати, многие удивляются: «Почему программа не догадалась сама?» А она не должна догадываться. УНФ — это не волшебная коробка, а рабочий инструмент. В нем все держится на настройках, и если их не включить, дальше начинается цепочка мелких ошибок. Сначала не тот остаток, потом не та цена списания, потом не совпадает себестоимость, а потом бухгалтер уже смотрит в отчеты с тем самым выражением лица, которое обычно бывает у людей, если им дважды за день сказать, что товар вроде есть, но фактически его нет.
По-хорошему, перед началом работы нужно привести в порядок склады. Не «создать один склад на все случаи жизни», а реально разделить их по смыслу. Склад сырья, склад готовой продукции, розничная точка, основной склад, ячейки хранения — все это не для красоты. Это помогает видеть не просто где лежит товар, а что именно лежит и кто за него отвечает.
Если склад в базе один, а в жизни у вас пять зон хранения, то учет быстро превращается в один большой мешок. И потом ищут уже не товар, а его тень. В УНФ склад — это не просто место. Это логистический узел, и от его типа зависит очень многое: как будет списываться товар, как он будет попадать в отчет, как покажется розничная цена, и не съедет ли у вас логика учета вообще куда-то в сторону.
Кстати, отдельная тема — это счета учета. В УНФ можно настроить свои варианты учета через копирование стандартных счетов, например для материалов и готовой продукции. Для бизнеса это полезно тогда, когда нужно видеть не просто «есть товар», а понимать его экономику: что это за запас, как он проходит через производство, где формируется себестоимость. Да, звучит чуть бухгалтерски, но без этого потом управленческие отчеты начинают врать очень уверенно и очень спокойно.
Если вам ближе короткие разборы без длинных пояснений, такие штуки иногда удобнее обсуждать в нашем Telegram-канале: там как раз хорошо видно, как одна настройка потом влияет на остатки, цены и движение товара. Не теория ради теории, а живые ситуации из практики, где человек уже почти продал то, чего на складе не было.
Почему товар в УНФ должен быть не просто товаром, а товаром с единицами, упаковками и характером
Вот тут начинается самое интересное. Товар в УНФ — это не просто название в справочнике. Если вы хотите вести учет нормально, а не «на глазок», придется признать простую вещь: один и тот же товар может жить в разных единицах измерения. И это не прихоть программы, а реальность склада.
Например, поступила мука в коробках, по 20 килограммов в каждой. А продаете вы ее по килограммам. Или пришла ткань в рулонах, а отпускаете вы ее метрами. Или товар на входе в штуках, а на выходе — в упаковках. Если в карточке товара не включить возможность нескольких единиц измерения, система будет видеть только одну форму учета. И тогда все дальнейшие пересчеты придется делать вручную. А ручной учет, как показывает жизнь, обычно заканчивается на фразе: «Ну примерно столько-то осталось».
В карточке товара это настраивается несложно: вкладка «Общее» → раздел «Товары» → галочка «Несколько единиц измерения». После этого можно создать упаковки и задать коэффициент пересчета. Вот этот коэффициент — вообще ключевая вещь. Если у вас 1 коробка равна 20 кг, программа должна об этом знать. Не «догадываться», не «примерно считать», а именно знать. Иначе коробка превращается в красивую, но бесполезную этикетку.
С учетом упаковок есть один тонкий момент, который часто упускают. Люди думают: ну ладно, заполним потом как-нибудь. А потом приходит партия, продается частями, и выясняется, что в базе осталось 15 кг, а физически коробка еще целая. То есть товар вроде бы есть, но в каком виде — непонятно. И если вы торгуете оптом, в рознице или работаете с фасовкой, это сразу бьет по остаткам и по расчету себестоимости. Не очень приятно, мягко говоря.
С характеристиками похожая история, только еще тоньше. Многие считают, что цвет, размер или модель — это просто описание. Но в УНФ это может быть отдельный учетный разрез. И вот тут уже включается логика: товар один по названию, но на складе он разный по характеристикам. Черный кепи — это не белый кепи. Размер 42 — это не размер 44. Для системы это разные строки учета, и слава богу, потому что иначе остатки по нужному цвету или размеру развалятся в один общий котел.
Чтобы работать с характеристиками, сначала включают опцию: «Настройки» → «Еще больше возможностей» → «Общее» → «Характеристики номенклатуры». После этого можно заводить цвет, размер, модель или любой другой значимый параметр. И дальше уже при поступлении и продаже указывать не просто «кепи», а «кепи, черный», «кепи, белый», «кепи, размер M» — как нужно именно вашему бизнесу.
Я как-то видел базу, где все кепи были заведены одной строкой. Черные, белые, зеленые — все в одну кучу. Формально товар был, а по факту найти нужный цвет было невозможно. И это классический случай, когда учет как будто есть, но пользоваться им нельзя. Поэтому лучше сразу один раз включить характеристики, чем потом пересчитывать остатки на коленке.
И да, если вы сейчас мысленно вспомнили свой склад и у вас там тоже «товар один, а по факту разный», значит, мы уже почти на одной волне. Дальше будет про то, как этот товар не теряется в перемещениях и почему документ иногда важнее самой поездки машины из точки А в точку Б.
Перемещение, остатки и тот самый момент, когда товар «исчез»
Вот это вообще любимая история. Товар физически уехал на другой склад или в магазин, а в программе он будто растворился. На одном складе уже нет, на другом еще нет. И начинается паника: «Где он? Кто его видел?». А всего-навсего не оформили перемещение как положено.
В УНФ перемещение товаров оформляется отдельным документом: «Склад» → «Перемещения» → «Создать». Там указывают склад-отправитель и склад-получатель, после чего документ проводят. И вот только тогда система понимает: товар ушел оттуда и пришел сюда. Это не просто формальность. Это точка смены ответственности, если говорить по-простому.
Когда перемещение не проведено, учет начинает врать. На складе А остаток уже не тот, на складе Б его еще нет, а менеджер тем временем обещает клиенту отгрузку. И все это обычно выясняется в самый неподходящий момент — перед отгрузкой, перед инвентаризацией или перед закрытием периода, когда уже ни у кого нет желания играть в детектив.
Особенно болезненно это чувствуется, если у вас есть несколько точек продаж или распределенный склад. Потому что товар в реальности едет, а в учете как будто стоит на месте. И потом в отчете видно, что запасы есть, но не там, где они нужны. Отсюда и вечная путаница: «На главном складе пусто, в магазине пусто, а товар вроде бы был». Не был. Он просто потерялся в документальном смысле.
Именно поэтому ордерная схема в УНФ так важна. Она разделяет финансовый документ и физическое движение. Сначала может быть один документ, потом другой. Это не лишняя бюрократия, а защита от ошибок. Накладная может быть оформлена, но товар еще не передан. Или наоборот — товар фактически пришел, а документ надо довести до ума. Для склада это критично, особенно если поток большой и люди работают не по одному столу, а на реальном движении.
Еще одна штука, которую часто недооценивают, — начальные остатки. Их обычно вводят один раз, но если там ошибка, потом весь учет начинает плавать. В УНФ начальные остатки вводятся через «Компания» → «Начальные остатки». И там нельзя ошибиться в датах, количестве или единицах. Потому что это фундамент. Кривой фундамент потом очень трудно выправлять, а иногда уже и невозможно без пересмотра всей базы.
Кстати, для производства это вообще отдельная песня. Если вы не просто перепродаете товар, а что-то делаете сами, тогда нужен не только склад, но и логика материалов, выпуска и готовой продукции. И вот тут уже без спецификаций учет становится совсем хрупким. Но это я, пожалуй, дальше отдельно разверну, потому что там есть хороший практический пример — как из муки и сахара вдруг должен получиться хлеб, а программа обязана в это поверить на основании нормальной спецификации, а не догадок.
Подсчет по истинному количеству: как избежать ошибок учета
Важный момент, который многие упускают на старте — это обоснование фактических остатков. Если у вас есть товар, например, *кепи*, и он пришел в количестве 20 штук, но не указаны характеристики, то вся партия оказалась одной строкой. Пусть это будет «кепи». Но дальше наступает момент, когда нужно продать именно черное кепи, а не белое. И тут наступает замешательство: остатки по цветам не считались, и операторы начинают хаотично исправлять данные вручную, что ведет к еще большим ошибкам.
Еще одна часто встречающаяся ошибка — это ожидание автоматического учета. Когда пользователь думает, что система сама все поймет и проведет нужные перемещения. А на самом деле, если не создать документ «Перемещение товаров», то товар просто пропадает. Все это сломает логику учета и усложнит последующие операции: клиент ожидает товар, а у вас его прописано не там.
Спецификации для успешного производства
Когда речь идет о производстве, нужно уделить внимание спецификациям. Многие почему-то думают, что это не важно, и можно обойтись без них, но в реальности это не так. Спецификации нужны не для красоты, а для учета всех компонентов, из которых создаётся конечный продукт. Если не прописать по 1 кг муки и 200 граммов сахара для выпечки, программа не будет знать, сколько сырья нужно для заданного количества изделия. Об этом надо помнить, ведь сложно создать хлеб без четкого понимания, сколько чего нужно.
Если вернуться к примерам из жизни, часто вижу ситуации, когда производство стоит просто потому, что нет точных спецификаций. И потом обращаются с вопросом: «Почему не получается выполнить заказ по времени?». Вот тут и всплывает ошибка: «Автоматическая настройка спецификаций сама по себе не работает». Необходимо все правильно прописать, чтобы избежать потерь в производственном процессе.
Где скрываются потери: контроль и отчеты
Не менее важен и контроль остатков. В УНФ есть замечательный отчет «Остатки товаров на складах», который позволяет взглянуть на весь товар в разрезе количества и остатка по конкретным характеристикам. Кажется, что ничего сложного. Но если параметры учета или способы учета были изначально настроены неверно, отчеты просто солгут. И тут, как правило, возникают вопросы: «Но как же так?». И это часто заметно в конце месяца, когда нужно делать ясные отчеты для бухгалтерии.
Еще один интересный момент: адресное хранение. Благодаря ему улучшится управление, и у вас не будет ситуации, когда партию продукта «съедает» затрата времени на поиск. Настроив ячейки, вы будете ровно знать, где и что лежит на складе. Это не просто помощь в поиске — это прямое влияние на эффективность работы вашей команды.
Так что здесь-то уже начинается настоящая логистика, которая, к сожалению, у многих почему-то остается за бортом. Важно помнить, что учет в УНФ зависит не только от того, что у вас есть на полке, но и от того, как организованы связи между всеми элементами учета, от складов до спецификаций.
Если вы хотите, чтобы все работало как часы, не забывайте: учет — это не просто наложение документарных функций, это целая структура, в которой каждый элемент имеет значение. А еще лучше нарисуйте схему, сделайте заметки, пока все процессы не уложатся в голове. Это позволит свести к минимуму риски, которые могут возникнуть из-за недостаточной осведомленности о своем товаре.
Готовы ли вы навести порядок? Каковы ваши наблюдения в использовании 1С УНФ? Делитесь своим опытом!