Программист 1С быстро, качественно, дешево! Вы верите этой фразе?

Качественно + Дёшево + Быстро = Утопия

Вы реалист? Тогда лучше сразу правильно расставьте приоритеты.

Качественно + Дёшево = Долго

Быстро + Дёшево = Халтура

Качественно + Быстро = Дорого

 

 

 

 

 

 

Данная статья возможно поможем Вам правильно распределить приоритеты при выборе программиста 1С для реализации ваших потребностей.

 

Часто приходится переделывать работу за другими программистами 1С.

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

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

 

Это нормально и встречается во всех специальностях. Сам набил много шишек пока нашел хорошего парикмахера, автослесаря и т.д.

 

Только с опытом приходит понимание как правильно делать доработку 1С, чтобы она корректно выполняла нужные операции и не приводили к нежелательным последствиям.

 

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

 

Не все задачи можно и нужно выполнять «в лоб» как этого хочет заказчик.

 Такие как:

• Удалите мне документы позапрошлого года
• Создайте обработку которая создаст номенклатуру, в ней укажите только Наименование и код.
• Не хочу в документе заполнять соглашение/договор/организацию - удалите мне этот реквизит или сделайте чтобы без него документ проводился.
• Давайте обновим бух базу , которая не обновлялась 2 года на последний релиз без создания резервной копии.
• Давайте внесем изменения в конфигурацию бух базы. (Бух базы постоянно требуют обновления и если делать не через расширение , то все изменения при обновлении будут стерты).
• Давайте переименуем номенклатуру и артикулы или контрагентов или организации

 

 

Пример 1

Конфигурация «Управление торговлей», версия не важна.

У клиента долг и оплата по контрагентам считается по заказам или по договорам.

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

Он ставит задачу «Хочу видеть, чтобы в отчете выводился долг и оплата по реализациям». Стоимость разработки значения не имеет.

 

Как работает конфигурация? Опишу как можно проще.

Дело в том, что в соглашении или договоре указывается как вести учет расчета с контрагентом (заказы, договор, реализации) и клиент при составлении договора указал «По заказам». Он этого не помнит , да и не понимает что это вообще значит.

Документы в 1С делают проводки. Из-за того что указан "расчет по заказам" долг и оплата по контрагенту будет вестись по заказам. Проводки будут соответствующие.

 

Что будет если решать задачу «в лоб».

1 Способ. Безобидно поправить отчет.

Берем отчеты «Взаиморасчеты с контрагентами» или «Дебиторская задолженность» или делаем свой отчет. Видим, что заказ всегда привязан к реализации и вместо заказа выводим в отчет реализацию, а заказ скрываем из отчета.

Все довольны, все работает, но… только пока у заказа клиента есть 1 реализация, если несколько, то клиент обращается с жалобой «Отчет неправильно работает».

2 Способ. Самый опасный. Сразу лезть в конфигурацию и уверенно править регистры.

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

Как нужно сделать.

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

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

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

Задача одна, а сколько всего можно сделать неправильно.

 

Пример 2

Еще один пример, исправлял в прошлом месяце.

Нужно чтобы из торговли в бухгалтерию переносились документы «Заказ покупателя» в «Счет на оплату».

Написана обработка, которая из торговли переносит документ в бухгалтерию.

 

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

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

И вообще такую задачу гораздо дешевле и эффективнее можно было бы решить через правила обмена данными. Ошибка исправлена, все довольны.

 

Пример 3

Где уже нельзя исправить ошибку. Можно конечно, но уже не целесообразно.

Новый клиент. Неправильно считается акт сверки. Обслуживается у кого-то, но хочет перейти, т.к. тот уже не справляется.

С виду вроде не сложная задача. Начинаю разбираться почему акт сверки неправильно считает суммы.

Акт сверки берет данные из проводок. И тут вижу. Организация указана в док-те одна, а в проводках другая(которая помечена на удаление). Сообщаю клиенту. Он говорит, что это их бывшая организация и программист таким образом делал переход.

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

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

 

Пример 4

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

И ведь разработчик с малым опытам вам так и сделает. А потом когда проводки документов у бухгалтера не пойдут он честно ответит - "Вы же так просили".

Отказывать было страшно, но я отказал )))

 

Пример 5

Купились постоянные клиенты на красивые лозунги маркетинга. Купите модуль "Управление отделом продаж" и продажи взлетят до небес.

Уговаривал их не покупать, сделаю сам что нужно и дешевле. Все равно пользоваться не будете. Нет, купили.
Мало того , что в обработке оказазалось что нужно ежегодно платить чтобы модуль работал, так он затронул все документы. Создавал свои документы, события.
За 2 года база с 7 Гб выросла до 450Гб и стала очень медленно работать.
Просят удалить , очистить....
Т.к. клиенты постоянные все сделал. Пока удалось уменьшить базу до 20Гб. Позже попробую еще меньше сделать. Удалил несколько миллионов документов и вложений.

 

Пример 6. Сделайте автоматическое создание док-тов.

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

Разработчик делает, обработка работает, документы создаются. 

Потом проходит время (может даже несколько лет) и оказывается что созданные документы при проведении дают неправильные проводки или не хватает проводок в них.

Причина в том, что не всегда все реквизиты документа видны на его форме. 

А ПРИ СОЗДАНИИ ДОК-ТОВ НУЖНО УКАЗЫВАТЬ ВСЕ РЕКВИЗИТЫ.

И заказчик это никак не проверит. Он и не знает про это.

Это как мне очень часто поступает задание. "Нужно создать номенклатуру из файла эксель. Заполнить только Наименование , артикул, код.". 

Там кроме этих реквизитов еще шт 15 нужно обязательно заполнить чтобы потом проблем не возникло.

 

 

 

Таких примеров множество...

 

Программисты 1с без опыта работы:

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

Всё это приводит к сбоям в базе и некорректной работе конфигурации.