Благодаря присвоению системного кода номенклатуры каждый объект, который реализуется предприятием, – будь то товар или услуга – получает уникальный идентификационный номер. Это позволяет различать товары при продаже, следить за их движением и вести учёт.
Но при работе с маркетплейсами может возникнуть серьёзная путаница с системными идентификационными кодами номенклатуры, которая впоследствии может сильно усложнить идентификацию и учёт товаров. В статье расскажем, в чём суть проблемы, как не допустить её возникновения и что мы в «Фингуру» делаем, если она уже возникла у наших клиентов.
Суть проблемы
Начнём с того, что системные коды номенклатуры для своих товаров продавец может создавать разными способами. Например, он может сделать это при создании номенклатуры в программе складского («Мой склад», 1С:УТ, 1С:УНФ) или бухгалтерского («1С:Предприятие») учёта. И в таком случае при создании карточки товара на маркетплейсах продавец может ввести свой системный код. Но если это не будет сделано, маркетплейс сам автоматически сгенерирует свой код. Причём если товар реализуется на разных маркетплейсах, то он получит разные коды на каждой площадке: один – на Ozon, другой – на Wildberries, третий – на СберМаркет и так далее.
Проблема заключается в том, что многие предприниматели (особенно начинающие) стремятся как можно быстрее реализовать свою продукцию, не генерируют свои системные коды и прибегают к этой автоматической генерации кодов на маркетплейсах. Они ещё не знают, с какой путаницей им предстоит столкнуться – это открывается лишь потом, когда они выгружают отчёты по продажам из личного кабинета маркетплейсов (отчёты агентов), загружают эту информацию в свои учётные программы и видят, что одна позиция (один товар) имеет в разных программах разные коды.
Из-за этого потом, при ведении бухгалтерского учёта, придётся вручную подбирать товары (а их могут быть тысячи). Попытки идентифицировать товары по наименованию тоже зачастую не упрощают ситуацию, ведь требования к наименованию товара на разных маркетплейсах могут различаться: где-то, например, в названии должен быть указан размер обуви, а где-то нет.
Изменить код товара в маркетплейсе потом будет невозможно. Сами маркетплейсы дают лишь одну рекомендацию для таких случаев: пересоздать карточки товаров с указанием уже другого, своего кода. Но это, во-первых, поможет лишь в том случае, если проблема была выявлена до продажи товаров, а во-вторых, даже если товары ещё не были проданы на маркетплейсе, пересоздание карточек (особенно при большом ассортименте товаров) – дело весьма трудоёмкое.
Как не допустить путаницы
В первую очередь, следует изначально выбрать основную программу для создания номенклатуры (и, соответственно, присвоения уникальных кодов). Потому что путаница и проблема с интеграцией информации о товарах может возникнуть даже в том случае, если продажа не ведётся на маркетплейсах – а, например, если номенклатура будет создана одновременно и в складской, и в бухгалтерской программе. Это также приведёт к дублированию позиций.
В идеальном сценарии работа с номенклатурой должна происходить, например, так:
- Номенклатура создаётся в бухгалтерской программе (или даже просто в Excel), товарам присваиваются уникальные коды.
- Затем информация выгружается в программу складского учёта.
- Присвоенные уникальные коды вводятся в личном кабинете маркетплейса при создании карточек товаров.
- Отчёт по продажам на маркетплейсе выгружается и вносится в учётную программу – и та сразу «понимает», какие товары были проданы.
Если проблема уже возникла
Поскольку мы в «Фингуру» регулярно сталкиваемся с такой путаницей у наших клиентов, которые пользуются нашим аутсорсингом бухгалтерских услуг, мы сделали специальную доработку к программе «1С:Предприятие». В каждый справочник номенклатуры мы добавили дополнительный реквизит – код маркетплейса. Благодаря этому при загрузке отчёта о продажах с маркетплейсов программа, обращаясь к справочнику, сразу понимает: это тот же самый товар, но реализуется он, например, на Ozon.
Стоит отметить, что 1С и сами завели подобный регистр, но на данный момент дополнительные реквизиты в нём есть только для двух маркетплейсов: Ozon и Wildberries.
Таким образом, программа с нашей доработкой идентифицирует товар по следующим реквизитам:
- Сначала – по «обычному» системному коду, который был присвоен самой программой.
- Затем – по коду маркетплейса.
- Затем – по наименованию товара.
- И наконец, если поиск по предыдущим реквизитам не удался, программа создаёт новый товар – с тем же кодом, который был указан в загруженном в неё отчёте.
Минус данного способа решения проблемы заключается в том, что для этого нужно заполнять справочник и указывать коды маркетплейсов. Тем не менее, это гораздо проще, чем потом перебирать товары вручную.
А как отразить это в складской программе?
В программе складского учёта (например, «Мой склад») возможности такой работы со справочником нет – то есть, для одного и того же объекта номенклатуры там нельзя указать сразу несколько кодов. Соответственно, в неё нельзя выгрузить отчёт по продажам из маркетплейсов и отследить, какое количество товаров было реализовано.
И в таком случае выход один: информацию о продажах черпать непосредственно из маркетплейсов. Выглядеть это может следующим образом: предприниматель купил товары, оприходовал их в программе «Мой склад», отгрузил эти товары в маркетплейс, а в складской программе отобразил эту отгрузку как выбытие товаров. После этого он смотрит в личном кабинете маркетплейса, как идут продажи и какие есть остатки товаров.
И несмотря на то, что товары отмечены в складской программе как реализованные, хотя право на реализацию товаров при работе с маркетплейсами всё ещё остаётся у самого продавца, в случае отсутствия продаж и возвращения товаров продавец сможет отметить это как возврат реализации. Это не совсем правильно с точки зрения учёта – поскольку затем, при передаче информации из складской программы в бухгалтерскую нужно будет вручную менять статус товаров с реализованных на отгруженные (менять тип документа). Но, во-первых, это происходит не так часто, а во-вторых, другого способа решения этой проблемы на данный момент нет.
Таким образом, самый простой способ решить проблему – это не допустить её возникновения. А именно: изначально выбрать основную программу для создания номенклатуры и присвоения товарам уникальных кодов.
Мы регулярно рассказываем вам о своей работе. Рекомендуем к прочтению:
- Как переход с авансовых платежей на фактические вернул бизнесу 900 тысяч рублей: кейс клиента «Фингуру»
- ФСС не принимает сведения о больничных и не оплачивает их: боремся с этой проблемой
Павел Тимохин
Эксперт Фингуру
