Материал помещен в архив

ПРОБЛЕМЫ И РЕШЕНИЯ ОРГАНИЗАЦИИ СКЛАДСКОГО УЧЕТА

В процессе постановки управленческого учета и бюджетирования на отечественных предприятиях часто допускаются однотипные ошибки в организации складского учета. Причем эти ошибки требуют существенных затрат на исправление.

В данном материале рассмотрим пути оптимизации складского учета.

Закупка-продажа товара через несколько собственных юридических лиц

Схемы закупки-продажи товара через несколько собственных юридических лиц законны и широко распространены во всем мире. Использование цепочки из нескольких юридических лиц, которые находятся в разных странах и пользуются различными условиями налогообложения, позволяет оптимизировать налоговую нагрузку на весь холдинг. Пример такой схемы представлен ниже.

Как видим, торговая надбавка распределяется по нескольким юридическим лицам. Причем вместо фирмы может использоваться дружественный индивидуальный предприниматель с патентной системой налогообложения.

Часто собственник надеется обойтись автоматизацией бухгалтерского учета в каждом из своих юридических лиц. Однако иногда даже минимальной автоматизации сознательно не проводится. Это относится к случаям, когда некоторые свои юрлица пользуются упрощенной системой налогообложения либо подготовка бухгалтерской отчетности передана на аутсорсинг.

Схемы консолидации информации

Предположим, что во всех юридических лицах бухгалтерия автоматизирована. Но даже в этом случае придется решать многочисленные проблемы. Главная из них - несинхронизированные базы данных: списки контрагентов и номенклатуры отличаются в каждой базе, т.е. товарные позиции не имеют единых стандартных кодов либо артикулов, а у контрагентов не всегда присутствуют их уникальные номера либо учетный номер плательщика (УНП), индивидуальный номер налогоплательщика (ИНН) и т.д.

Названная проблема порождает следующее.

1. Собственник не может отследить движение товара по цепочке своих юридических лиц, оценить эффективность работы с конкретными товарными позициями с точки зрения всего холдинга.

2. Из первого пункта вытекает невозможность реальной оценки прибыльности бизнеса. Собственник может увидеть только объем продаж конечным покупателям, однако себестоимость проданного товара требует отдельного сложного расчета.

3. Арифметическая сумма прибыли или объема продаж по каждой компании также будет неверной - завышенной за отчетный период за счет внутренних продаж, которые, как известно, должны вычитаться.

4. Необходимость исключения внутренних долгов из арифметической суммы дебиторско-кредиторской задолженности по своим компаниям и др.

Названные проблемы обойти нельзя. Разумеется, можно поступить, как аудиторы: собрать все бухгалтерские данные и свести их вручную либо при помощи таблиц Excel. Но это разовое решение, которое не годится для оперативного управления бизнесом.

Как показывает практика, единственно правильный путь в такой ситуации - создать отдельную базу данных для консолидации и экономического анализа. Какая это будет база, зависит от предпочтений собственника.

Перед запуском такой базы данных необходимо провести разовую трудоемкую процедуру стандартизации справочников: исключить дублирующиеся элементы, у всех контрагентов можно указать УНП либо ИНН, всем товарным позициям присвоить уникальный артикул. Желательно, чтобы артикулы несли в себе смысловую нагрузку: например, первые разряды могут означать товарную группу, вторые - производителя, третьи - уникальный код товара и т.д.

После этого необходимо обеспечить корректную работу консолидированной базы. Покажем два варианта объединения информации.

В первом случае (схема 2) программисты должны запустить систему синхронизации бухгалтерских программ так, чтобы при появлении новых товарных позиций либо контрагентов в любой из баз данных эта информация автоматически добавлялась во все остальные базы.

Таким образом, будет поддерживаться единообразие информации и уникальность товаров и контрагентов в рамках всего холдинга. Одновременно настраиваются модули экспорта-импорта товарных накладных из бухгалтерских программ в консолидированную базу данных. При этом продажи между своими компаниями должны автоматически трактоваться как внутреннее перемещение товара либо внутренняя продажа по трансфертной цене. Это необходимо для того, чтобы не происходило искусственного завышения реальной себестоимости товара, объема продаж и дебиторско-кредиторской задолженности.

Второй вариант консолидации требует добавления еще одной базы данных - для первичного учета. При кажущемся усложнении схемы она обеспечивает более удобную и прозрачную работу холдинга (схема 3).

В этом случае вся первичная информация по товарному движению изначально вносится в специализированную программу для складского учета. Как правило, для этих целей используются «1С:Торговля» либо модули складского учета корпоративных систем «Галактика», «Аксапта» и др. Программа для первичного учета должна быть простой и удобной, чтобы ее могли быстро осваивать складские работники и менеджеры по продажам. Одновременно эта программа должна позволять учитывать товар по нескольким юридическим лицам. Если эти требования выполняются, то работа с товарными потоками становится наглядной и удобной: менеджер при помощи одного программного продукта может видеть наличие товара у всех юридических лиц, контролировать его движение между ними и выписывать счета и накладные от имени любой компании. После ввода информации в программу для первичного учета все накладные должны автоматически переноситься в соответствующие бухгалтерские базы данных, а также в базу для экономического анализа и бюджетирования.

Организация партионного учета

Справочно Партионный учет - учет товаров, который составляется отдельно для каждой партии товаров. Его суть состоит в том, что каждая партия товарных запасов получает товарный ярлык с номером. Далее в расходные документы вносятся номера партий, а в ярлыке партии указываются номера документов и количество отпущенных товаров. Следует обратить внимание на то, что для каждой партии товаров ведется свой отдельный аналитический счет и в нем ведется запись движения тарного места. Ежемесячно с использованием данного аналитического счета составляется оборотная ведомость, в которой указывается номер партии для каждой группы товаров, а также для каждой партии указываются сумма и количество тарных мест.

Может возникнуть вопрос: зачем нужна еще одна база для экономического анализа? Дело в том, что товарная номенклатура даже в единой программе для первичного учета не всегда идеальна. Серьезную проблему при консолидации информации представляет использование бухгалтерских товарных партий.

Напомним, для чего используется партия товара. Партионный учет нужен для расчета себестоимости проданного товара и складских остатков в том случае, если в учетной политике используются методы ФИФО либо персональная идентификация партий (себестоимость каждой единицы). Связывает эти методы четкая сортировка всего товара на складе по приходным накладным.

На реальном складе названные методы применяются крайне редко из-за их технической сложности: кладовщик должен маркировать каждую упаковку и отпускать товар строго в соответствии с бухгалтерской учетной политикой. Обычно склад работает по принципу «бери с ближайшего стеллажа». И этому принципу лучше всего соответствует простая методика расчета средневзвешенной себестоимости. Однако бухгалтерия часто использует иные методы: это позволяет ей оптимизировать налогообложение, а в белорусских условиях - еще и контролировать предельную оптовую надбавку.

При постановке на учет регулярно возникают ситуации, когда бухгалтеры вводят в программу партии товара как обычные товарные позиции. При этом справочник номенклатуры раздувается в разы, а выбор товара для продажи происходит путем ручного перебора этих партий, так работали лет 10 назад. Сейчас практически любая бухгалтерская программа обеспечивает возможность «незримой» работы с партиями, т.е. бухгалтер видит одну товарную позицию, а те несколько партий, которыми поступал товар, обрабатываются автоматически.

Внедрение правильного партионного учета уменьшает справочник номенклатуры в несколько раз и позволяет производить эффективный экономический анализ продаж.

Заметим, однако, что даже при правильной постановке учета партии все-таки иногда «всплывают» в справочнике номенклатуры. Это обусловлено тем, что один и тот же товар (одинаковые наименование, дата изготовления, один изготовитель) может поступить на предприятие разными путями: часть закупили в России, часть - в Беларуси у посредника, часть вообще взяли на комиссию. С экономической точки зрения это один и тот же товар, но в первичной или бухгалтерской программе он будет представлен тремя позициями. Именно поэтому нужна не только программа для первичного учета, но и экономическая для окончательной консолидации информации.

Территориально-распределенные компании

Рассмотрим ситуацию, когда холдинг имеет территориально распределенную структуру: несколько офисов и складов в разных городах. Возникает вопрос: если планируется единая первичная база данных, как организовать ее работу в этом случае? Существует два варианта решения данной проблемы.

Как правило, современные учетные программы имеют встроенные механизмы репликации (схема 4), т.е. на одном из офисов устанавливается центральная база данных, на остальных - периферийные.

Периферийные базы с определенной периодичностью (раз в день, раз в час и т.д.) обмениваются информацией по электронной почте с центральной базой. Процедуру синхронизации можно выполнять как вручную, так и автоматически. Достоинства данной схемы: дешевизна каналов связи и серверного оборудования. Однако следует иметь в виду, что общую информацию видно с некоторым отставанием - на момент последней синхронизации.

Второй вариант предполагает использование единой базы данных на центральном сервере (схема 5).

Удаленные пользователи подключаются к ней через Интернет как удаленные терминалы. Это решение удобно и красиво, но требует серьезной технической проработки и более дорогих каналов связи. Как правило, в пределах Республики Беларусь такая схема с терминальным доступом работает достаточно надежно.

Отметим, что проблемы складского учета изложенными тезисами не исчерпываются. Однако оптимизацию складского учета начинать следует именно с них.

25.04.2014

Александр Синкевич, директор компании «Sinkevich Technologies»