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

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

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

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

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

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

 

 

 

 

 

 

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

 

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

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

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

 

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

 

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

 

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

 

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

Пример1 - это самая распространенная задача на этот счет.

 

Пример 1

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

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

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

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

 

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

 

Пример 2

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

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

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

 

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

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

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

 

Пример3

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

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

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

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

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

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

 

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

 

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

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

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