Каталог предприятий

 

Информационные технологии

23.10.2008

Проблемы учета товара и документооборота на складах при применении программы 1с

Оценка
Эксперты:
2.00
Анонимы:
1.68
Просмотров:
36660
Комментариев:
3
skudilov аватар
(рейтинг: 0.00/0.00)

Статья написана в соавторстве с Виктором Барановским (Логистическая мастерская)

На данный момент наиболее распространенный класс применяемых программ на складах – учетные системы семейства 1с. Их основная цель – ведение автоматизированного учета движения товарно-материальных ценностей. Их весомое преимущество – простота внедрения и вполне достаточная функциональность для реализации контрольных функций за состоянием товарных запасов. Но, к сожалению, также существуют глобальные проблемы в работе таких баз, в основном связанные с нарушением логики бизнес-процессов и недостаточной квалификацией сотрудников, работающих в этих учетных системах. Самое первое и необходимое, что нужно сделать – это настроить работу системы так, чтобы учесть (и минимизировать) человеческий фактор. Людям свойственно делать ошибки, и самая главная проблема на сегодняшний день – настроить работу системы таким образом, чтобы минимизировать частоту их возникновения и настроить рабочий процесс так, чтобы допущенные ошибки максимально быстро выявлялись и исправлялись, а не порождали цепочки неправильных документов. Сегодня недостаточное внимание уделяется этим важнейшим моментам. Основные замечания стараются отнести к некорректной работе программы-учета, не углубляясь в причины возникновения проблем. При этом персонал с квалификацией ниже средней – считает, что учетная система обладает «собственным интеллектом» и должна ориентироваться не на последовательность вводимых команд, а на «ход мыслей» оператора, работающего в программе. В данной статье мы попытались рассмотреть наиболее часто возникающие проблемы и варианты их решения. 

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

Пример:        

«зарядное устройство NOKIA» или       

«NOKIA зарядное устройство» или      

«зарядное устройство NOKIA LCH-12 » 

Решением является жесткая формализация процесса внесения  в базу нового элемента номенклатуры, с прописанием иерархии свойств товара, вносимых в базу данных («паспорт товара») и жесткой последовательности формирования названия, отражающего свойства товара, например

- введите группу товара

зарядное устройство

- введите марку производителя

NOKIA

- введите модель товара

LCH-12

- введите дополнительную характеристику товара (например, цвет)

black

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

2.      Применение штрихкодирования в учете ТМЦ. Если рассмотреть вариант учета ТМЦ с использованием штрих-кода, то и это не панацея для решения проблемы. Сегодня на рынке существует огромное количество наименований единиц товара, практически всем присвоен штрих-код, и теоретически штрих-код товара не должен повторяться, но на практике - очень часто через склад проходит товар с повторяющимися штрих-кодами, и мы опять сталкиваемся с «задвоением», но уже кодов ТМЦ с различными наименованиями. Проблему создает широкое применение «внутренних» штрих-кодов и распространенная практика производителей по повторному использованию уже присвоенных штрихкодов при обновлении ассортимента. А в основе проблемы – все та же проблема квалификации персонала, принимающего решение. Попытка устранить задвоение штрих-кодов путем создания на некоторые товары собственного «внутреннего» штрихкода решает одну частную проблему, но только увеличивает общее «поле неопределенности», если процесс не будет максимально жестко формализован (включая правила нанесения стикера поверх штрих-кода поставщика и механизм контроля правильности изготовленного самостоятельно штрих-кода). Пути решения – конечно, введение EDIкак программа-максимум. Также результат приносит применение ТСД и дополнительного ПО для работы со штрихкодами. В данном случае нас интересует способность при сканировании штрих-кода предоставить работнику перечень наименований, имеющих данный штрих-код, и предложить подтвердить одно из предложенных наименований товара.  

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

4.      Проблема перепроведения документов задним числом и перепроведения всех документов  в базе, положительные и отрицательные остатки ТМЦ.

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

Точка актуальности (далее ТА) - это момент времени, дата и время последнего проведённого документа, который показывает, что на этот момент в базе рассчитаны все остатки и задолженности, и при необходимости их получения - расчёт производить не надо. Например, если для сравнения сделать "Отчёт по остаткам товаров" на момент ТА и на любую другую более позднюю дату, то для построения первого потребуется меньше времени, так как нет необходимости рассчитывать итоги, а надо только  сформировать печатную форму.

Период хранения итогов. Как говорилось ранее, чтобы рассчитать остаток не на момент ТА, необходимо пересчитать все приходы и расходы от начала базы до заданной даты. Но если, к примеру, база имеет несколько десятков (или сотен?) документов в день и ведётся не один год, то такой расчёт затянется на длительное время. На самом деле пересчитывать нужно только приходы и расходы с начала отчетного периода (обычно – месяца) до заданной даты. На начало же каждого месяца итоги сохраняются при ежемесячной процедуре открытия нового периода (месяца).    В системе товарооборота существует такое понятие, как партии товаров. Упрощенное определение: партия – это совокупность ТМЦ  одной приходной накладной, которая формируется в группу со своим индивидуальным номером. В компьютерных базах данных партии хранятся в таблицах регистров. Основная задача партий – это предоставление информации о движении конкретного ТМЦ, и возможность разделить поступления ТМЦ на склад по различным признакам. Пример:  

01.04.07 на склад был принят товар «X» 15 шт.,

15.04.07 было повторное поступление этого же товара 20 шт., но от другого поставщика и по другой цене.

За период с 01.04.07 по 30.04.07 было продано 7 единиц товара.

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

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

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

 Обычно списание товара по партиям производится по методу FIFO (по себестоимости первых по времени поставок). Если в одно время было два поступления одинакового ТМЦ от разных поставщиков, списание не будет хаотичным. Сначала со склада спишется весь товар от первого поставщика (первая партия), и только после полного списания, начнется списание от второго (вторая партия).

      Вот что мы видим, когда происходят изменения и перепроведения документов задним числом. 

Вариант: положительные остатки

По первой поступившей партии уже полностью списан товар, остаток =0,  и началось списание со второй партии, общий остаток ТМЦ на складе = 6. Но сотрудник, работающий с документами, по какой-то причине изменяет количество в одном из ранее проведенных документов, который уже списал часть товара по первой партии. В документе изменяется количество ТМЦ с 4 на 3, и после изменения перепроводится документ.

На первый взгляд ничего страшного не произошло, но если продолжить списания ТМЦ и в итоге посмотреть движения по партиям, мы увидим следующее: у первой партии на остатке появилась 1 шт, общий остаток на складе = 7. Во время дальнейшей работы со второй партии без проблем спишутся 6 шт., ведь как мы уже говорили,  товар списывается по FIFO, и для учетной системы первой партии уже «не существует» (несмотря на то, что остаток по партии числится), т.к. уже началось списание со второй партии.

В итоге на складе числится 1 единица товара, а провести ее в документе невозможно без выяснения, ручного вмешательства и исправления проблемы. Со стороны пользователей это выглядит как «глюк базы», а на самом деле - это «человеческий фактор». Вариант: отрицательные остатки

Итак, сейчас 17.04.07 время 13:00, идет списание с партии2 …

Партия1, товар «Х», остаток по партии  = 0.Партия2, товар «Х», остаток по партии  = 3.

Общий остаток товара «Х»  = 3

Списание последней единицы ТМЦ партии1, было 17.04.07 в 11:00.

Вдруг сотрудник, работающий с документами, по какой-то причине создает новый документ («перемещение» или «реализация») на дату и время 16.04.07 – 17:00. Классический пример создания документа задним числом. Причины обычно очень убедительные (для автора такого документа). В новом документе от 16.04.07 – 17:00 товар «Х» = 1шт.. Сотрудник проводит этот документ датой и временем 16.04.07 – 17:00. Программа  позволит провести такой документ, но перед этим запросит: какой датой это сделать. Если сотрудник оставит дату без изменения, то по учету на 16.04.07 – 17:00 списание по партии1 еще не закончилось, товар есть на остатке, и документ при проведении спишет товар в минус.

В результате мы видим:

Партия1, товар «Х», остаток по партии  = -1.

Партия2, товар «Х», остаток по партии  = 3.

Общий остаток товар «Х»  = 2.

  В ходе дальнейшего списания - со второй партии без проблем будет списано (и отгружено со склада) 2 шт. товара партии ?2. В итоге мы увидим:

Партия1, товар «Х», остаток по партии  = -1.

Партия2, товар «Х», остаток по партии  = 1.

Общий остаток товар «Х»  = 0.

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

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

5.      Проблема работы в распределенной базе.Если учетная база является распределенной, то возникают коллизии и «накладывания» одних проводок на другие, с замещением корректных документов некорректными.Пример: С центрального склада А отправляется товар на склад (магазин) В. Допустим, что информационный обмен между центральной базой и удаленной проходит каждый час. Расстояние между пунктами А и В небольшое, и автомобиль доставит товар за 20 мин. Предположим, что в базе принят такой порядок движения ТМЦ:Создается «родительское перемещение» со склада А на магазин В, после его проведения товар списывается со склада А на «транзитный склад». На транзитном складе учитывается товар, перемещаемый между подразделениями компании. Проводить «родительское перемещение» необходимо, для того, чтобы были видны реальные остатки склада А для дальнейшего формирования документов на перемещение. Практика резервирования товара – не применяется исходя из операционной политики компании.Складу В для принятия товара нужно создать «подчиненное перемещение» от родительского и провести его по учетной системе. Тогда товар по учету перемещается с «транзитного склада» на склад В и становится доступен к реализации.На складе А сформировали «родительское перемещение» и провели списание по учетной системе, но товар еще не отобрали. В базе склада В документ виден, как уже проведенный. В течение следующих 30 мин на складе А отобран товар, но в родительское перемещение были внесены изменения (например, недостача одного из отбираемых товаров из-за пересортицы или обнаруженного дефекта). Через 50 мин. товар доставлен на склад В. Склад В еще не получил с синхронизацией измененный документ в свою учетную систему. В результате «человеческого фактора» (не сверены реквизиты накладной – сумма, количество позиций, количество штук) – сотрудник склада В подтверждает прием товара в учетной системе по старому варианту перемещения и создает соответствующее «подчиненное перемещение». После синхронизации – «родительское» и «подчиненное» перемещения не совпадают, на транзитном складе появляются положительные или отрицательные остатки товара, в зависимости от сделанных изменений в «родительском» документе на складе А.В результате необходимо очередное выравнивание остатков на складах учетной системы, с многочисленными изменениями уже проведенных документов и нарушениями хронологии последовательности отгрузки по партиям. Решением этой проблемы  является присвоение статуса документа, с разграничением по правам и признакам. Документы создаваемые в системе учета, могут иметь следующие статусы:

- Запланирован – документ создан, работы с документом не начаты, автор документа (например менеджер по продаже) может вносить любые изменения.

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

- Завершен – задание выполнено, оператор склада-грузоотправителя теряет право вносить изменения в документ, оператор склада-грузополучателя получает возможность подтверждения приема товара.

Изменение статуса документа производится вручную (максимально просто реализуемый алгоритм) выставлением-снятием соответствующих «флагов» или «галочек» в полях документа.

 

Пример. 

В «родительском» перемещении добавляется отметка статуса документа. Отсутствие отметки «накладная проверена» не дает возможности оператору склада – грузополучателя создать и провести по учету подчиненное перемещение. Устанавливается определенный набор прав с разграничением доступа к документам по признаку «Проверен». Если отметка не стоит, то склад-отправитель может корректировать документ, но склад-получатель не может создать и провести подчиненное перемещение. После установки отметки – операторам склада-отправителя доступ на изменение документа запрещается, и в свою очередь, разрешается прием товара на склад-получатель. 

6.      Проблема партионного учета при резервировании.     Практика резервирования товара имеет большие преимущества, позволяя упростить схему документооборота. Но в работе при этом также могут возникнуть проблемы. Так называемое «жесткое» резервирование подразумевает блокирование проведения транзакций по определенному количеству определенной партии. В совмещении с практикой FIFO– в результате существенно осложняется отбор товара, возрастает посерийная пересортица. Или – склад вынужден несколько партий иметь доступными к отбору, что существенно увеличивает нагрузку на зону комиссионирования.Поэтому считаем, что предпочтительнее «мягкое» резервирование, которое уменьшает количество доступного к отгрузке (перемещению) товара, но при этом не «привязывается» к определенной партии. В сочетании с последовательностью проведения транзакций, совпадающей с последовательностью отбора товара – данная практика позволяет существенно уменьшить количество ошибок посерийного учета. 

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

ewg аватар
s 322

      Отсюда прямая зависимость работы всего склада от кадрового вопроса.

                 Если посчитать сколько теряют денег на таких "мелочах", то налаженная работа склада есть сильный   козырь компании.

     

 

Текущая оценка коментария: - 0  - 0  - 0  (эксперты) / - 0  - 0  - 2  (анонимы)
Ваша оценка:
mihail аватар
Михаил

1) Толково написано. Есть небольшой баг по поводу положительных остатков по партии партии - проблем со списанием остатков партии 1 не будет, просто она не будет списана по методу Fifo, т.е. не будет соблюдена последовательность.

2) А мне в принципе к тому что написано добавить особо нечего - все в учетных системах зависит на 95 % от людей, которые ними пользуются, а в остальном статью нужно давать читать всем пользователям баз, чтобы они не творили в них чудеса.

3) А так - все правильно, молодцы - на програму пинать нечемо, сначала нужно четко распределить последовательность выполнения бизнес-процессов.

Текущая оценка коментария: - 0  - 0  - 3  (эксперты) / - 0  - 0  - 3  (анонимы)
Ваша оценка:
ravik аватар
Гусев Василий Викторович

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

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

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

Текущая оценка коментария: - 0  - 0  - 4  (эксперты) / - 0  - 0  - 5  (анонимы)
Ваша оценка: