История одной автоматизации

История одной автоматизации.

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

С 94 года занимался сопровождением 1С. Начиная с V4. По работе было необходимо. Потом читал лекции "Автоматизированная система обработки экономической информации". Основа 1С V6. Программировать в V7 не доводилось.

В 97 году занялся разработкой программно-технического комплекса контроля знаний. В этом комплексе я видел прямо панацею от всех бед в образовании. Конечно, я был влюблен в свое детище, и мог говорить о нем где угодно и с кем угодно. Разработали, назвали "Test2000", получили Свидетельство на полезную модель и установили 3 комплекса.

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

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

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

Изучаем обстановку.

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

Учет ведется на 3 ПК. В "арсенале" предприятия: 1С Бухгалтерия - сетевая, 1С Торговля - сетевая, 1С Расчет. Две последние программы не внедрены в производство. Главный бухгалтер купивший эти программы уволился, а вновь принятые не освоили. Магазин оформлен как ЧП, упрощенная форма учета. Бухучет особенно не нужен, а типовая конфигурация 1С Торговли слишком сложна. Вот такая картина.

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

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

Я не буду анализировать конфигурацию, могу просто сказать, что обнаружились просто ошибки. Например, списание по среднему. Накопились записи в базе данных типа - количество 0 сумма остатка 1 коп. Но все же она работала.

Заработал учет, однако один оператор никак не успевала ввести данные продаж. Началось накопление чеков. Отставание продолжало нарастать. Вот здесь и понадобился наш комплекс.

До этого была еще одна беседа, коммерческий директор за "круглым" столом рассказал о конфликте в коллективе. Я попытался обЪяснить этот конфликт со стороны ошибок менеджмента. Рассказал несколько примеров из книжки Тейлора "Принципы научного менеджмента" изданной еще в 24 году. Эта книжка подвинула руководство на применение науки в управлении. Четко сформировали задачи: учет, контроль, управляемость.

Первым делом решили оторвать продавцов от наличных денег. Вспомнились старые советские магазины, с кассой, с учетом, с передачами. Я, конечно, наблюдал эту "перестройку" со стороны, но иногда подбрасывал идеи. Советовать так легко! Я нарисовал схему передачи ответственности, вспомнили накладные и прочий бюрократизм. До накладных дело не дошло, но кассу сделали. Результат сказался незамедлительно. Уволилось 50% продавцов.

Причины обЪяснять не буду. Могу сказать, это не самые предприимчивые продавцы. Они просто подумали, что остались без "шары". А она еще была!

Тем временем, мы переписали ОС пультов под торговлю. Написали монитор для слежения за пультами. Теперь было необходимо связать 1С с нашим монитором. Поскольку автор конфигурации ретировался, Я взялся я за V7. Когда помощи ждать не откуда, приходится писать самому. Прикладывал этот язык и так и эдак к известным мне языкам, BASIC не BASIC, PASCAL не PASCAL, ну уж точно не С++. Потихоньку начал "вЪезжать".

В итоге я написал конвертор, состоящий из отчета и документа. Отчет сбрасывал в текстовый файл все товары в отделах и на складе, а документ - "Чек" забирал все продажи из DBF файла. Так оказалось проще всего. Конечно, данные сбрасывались в Торговлю после рабочего дня. Через месяц учет шел день в день. Стали проявляться интересные вещи. Например, по учету товара нет, на прилавках есть. Или, наоборот, по учету есть, на прилавках нет. Клиенты очень часто возвращают товар. Просто так, не нравится. Продавцы еще имели право оформлять возврат. Хорошая штука этот ВОЗВРАТ.

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

"Нажал F1, ввел код товара и получил справку о наличии товара. Нажал F2 и выписал чек, причем считать ничего не надо, просто код товара и количество. А на экране написано и наименование, и стоимость. Завершил чек и сумма по чеку. Песня. А главное все сразу в компьютере".

Звучит вопрос с задних рядов: "Это что, мы без шары остаемся?"
Программист засмущался "Вообще то да" - прозвучал грустный ответ программиста.
Здесь вмешивается молоденькая девочка: "А ВОЗВРАТ делать можно?". "Да, конечно. Нажал F5 и выписал возвратный чек". Она обращается к подругам и говорит: "Девочки не волнуйтесь, все нормально!"

Сделайте вывод, лазейка найдена не видя комплекса, а что будет, когда начнется работа? Наши люди на одну зарплату не живут!

Кстати, можно открыть рубрику - Воруют, о способах воровства и борьбы с ним.

Второе пришествие автоматизации.

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

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

В конце 2000 года обратились они ко мне с просьбой написать конфигурацию. К тому времени я уже поднаторел в V7, подправляя существующую. Проблемы магазина мне были известны, однако не было опыта написания конфигураций с "нуля". Я взял месяц сроку, и сел за разработку. К январю 2001 года я завершил ее. В январе по ходу дела отладил ошибки. В магазине провели ревизию и приступили к вводу остатков. Общий срок разработки и отладки составил 2 месяца. Естественно, работал по вечерам и в выходные. Не бросать же основную работу.

Когда в магазине использовались пульты ввода данных, все товары маркировали двумя уровнями. Номер поставщика, код товара. Дошли до трехзначных чисел в поставщиках, и пятизначных чисел в коде товара. Это произошло потому, что в предыдущей конфигурации не было учтено изменение цены. И один и тот же товар, но закупленный по разной цене, кодировался разными кодами.

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

Рис.1. Пример маркировки товара.

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

Благодаря такой организации ввода, торговый день вводится за 40-60 минут одним оператором. Каждый товар привязан к поставщику и менеджеру. ОбЪем справочников сократился, так как он не связан с ценой приобретения. За каждым видом товара закрепился его индивидуальный код. Менеджерам стали начисляться денежки только за проданный товар. Менеджеры начали отвечать за скорость реализации товара.

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

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

Рис.3. Пример отчета "Расчеты с поставщиками".

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

Вот здесь я и попался. В марте месяце мне позвонили и сказали, что обнаружены документы с отрицательным остатком. Сбой учета, караул! Я помчался разбираться. Ошибка оказалась проста. Я не учел, что товар с одним кодом может продаваться несколько раз за день. А точнее, не проверил, как повторные строки, будут влиять на остатки. А бухгалтер вводит все продажи одним чеком. Поэтому, если в документе есть остаток, и он больше чем списываемое количество в строке чека, все строки списываются с одного документа. Так как изменение состояния приходного документа происходит после проведения чека. Алгоритмическая ошибка.

Я написал отчет и получил все чеки с дубликатами. Не помню причину, почему я не написал обработку для удаления дубликатов, все удаляли вручную. Здесь я столкнулся с тем, что нельзя решить средствами макроязыка. Я не смог выйти программно из ручного редактирования строки. Местные франчи, посоветовать ничего не смогли. Нужно нажимать Esc. Они больше внедренцы, чем программисты.
Проблему обошел так, добавил кнопку "Дубликат" и присвоил ей горячую клавишу F2, ближайшую не занятую к Esc. Теперь по процедуре курсор прыгал в строку дубликата и становился на поле "Количество". Оператор вводила новое количество (не сумму, а слагаемое), после чего в ячейке отображалась сумма, а для успокоения оператора выводится вся арифметика в окне сообщений. Конечно, это несколько замедлило ввод. Но не сильно. Минут на пять, десять.

Другие проблемы начались к лету. Когда база данных выросла. Замедлилась работа при работе в сети при проведении документов, при формировании отчетов. Конечно, в магазине одноранговая сеть 10Mb/s на WinME, сервера нет. На компьютере с базами данных работает оператор-бухгалтер. При работе в монопольном режиме скорость отличная, при работе в сети "отстой", как говорит мой сын. Поскольку менеджеры не вводят документы, а пользуются только отчетами, поступили так. Установили копию программы на их ПК в локальном режиме. Создали копию баз данных. Теперь обе машины могут работать в монопольном режиме. Менеджеры быстро получают отчеты. Со всем приходом и продажами справляется один бухгалтер. Со второй машины может подключаться второй бухгалтер в моменты "запарок". База данных сбрасывается ежедневно менеджерам.

После этого мои визиты в магазин закончились. Конфигурация работает безукоризненно.

Что дала данная автоматизация магазину и его администрации.

Во-первых, ликвидировали склад. Расширили торговые площади. Скорость реализации товара известна, всегда можно подвезти. Во-вторых, проанализировали прибыльность товара. В этом году началась специализация магазина. Из 5000 наименований товара 80% прибыли принесла только одна тысяча.
В-третьих, стала подконтрольной работа менеджеров. Заработная плата зависит теперь только от реализации.
В-четвертых, налажены взаиморасчеты с поставщиками. Сверки проводятся в течение нескольких минут. До автоматизации это была основная работа. Делалась даже ночами.
В-пятых, стало известно, сколько воруют.
По мнению администрации, затраты на автоматизацию во много раз меньше, чем убытки от бесхозяйственности. При нормальном анализе, можно определить момент начала воровства. По обЪемам продаж, например. Так была пресечена попытка создания магазина в магазине. Продавцы вошли в сговор с менеджером, и подыскивали клиентов закупающих большие партии товара. Отправляли клиента к менеджеру, та предлагала им товар по меньшей цене, и с другого места. Товар поставлялся напрямую с оптового склада. Налоги и аренду платить не надо. Прибыль вся твоя. Уволили. Продавцов не знаю, а менеджера точно. Девочка "выросла".

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

Напоследок хочу рассказать об опыте неудачной автоматизации. Ко мне обратились работники другого магазина, с просьбой поставить им конфигурацию. Богатого магазина. Я задал им вопрос, хозяева они магазина или наемные работники. Они ответили, что наемные работники. Я им ответил, что они не купят конфигурацию, потому что она написана, для борьбы с воровством, и им она не выгодна. А то, что она быстро работает у их партнера, это еще и менеджмент, и маркировка. Необходимо перестроить работу всего магазина. Без маркировки скорость ввода можно достичь или распределенным вводов данных, или штрих кодами. А это затраты, превышающие стоимость конфигурации. Конфигурацию не купили.

Вокруг 1С:Предприятия много ломается копий. Кто ее ругает, кто хвалит. Я отношусь к этому иначе. Как к инструменту. Я знаю много СУБД. Почему я взялся за реализацию именно на этой базе? Во-первых, работники уже привыкли к ней. Во-вторых, система документно-ориентированна, можно симулировать реальную работу с документами. В-третьих, скорость разработки высока. СУБД ведь СПЕЦИАЛИЗИРОВАННАЯ. Добавить бы в 1С синтаксис помощник как DataEase, цены бы ей не было. Именно на DE я учился работать с базами данных. А так инструмент, как инструмент. Конечно на Delphi и Builder круче, меньше ограничений, но дольше и дороже.

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

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

Так что проблемы 1С лежат в области маркетинга. Слишком много развелось организаций типа ККК - Как Кого Кинуть. Не люблю я этих франчайзи.



Гость, Подготовься к сдаче отчетности за 6 месяцев!

ВЕБИНАР про сдачу отчетности за II—квартал 2022 года

Проверь все ли изменения в налогах и учете учтены!

На вебинаре «Новое в отчетности за 6 месяцев 2022 года: как отчитаться без штрафов» вы узнаете:

  • как будет сделан обзор изменений и разъяснений ФНС по НДС;
  • про налог на прибыль и налог на имущество организаций
  • а также об информационных письмах и рекомендациях Минфина по применению новых ФСБУ.

Успей занять место на вебинаре!

Записаться (Осталось 10 мест)