Рубрики
Ошибки в платформе 1С

Ошибка при обработке события элементов на форме

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

Рабочая система: 1С 8.3.16.1063 + MSSQL 2012.

Создаем документ с табличной частью. Создаем форму документа и размещаем на ней реквизиты, включая табличную часть. Теперь наша задача — отследить изменения пользователя реквизитов табличной части и по установленным нами правилами сделать пересчет служебных данных, проверки корректности заполнения и т.д.

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

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

На выявление этого косяка я потратил 30 минут. Печально, но это 1С и подобных косяков будет еще великое множество (на их официальном портале их тысячи неисправленных висит и никак не уменьшается).

Удачи вам в неравной борьбе с 1С.

Рубрики
Ошибки в платформе 1С

Неправильные данные выполнения запроса движений и остатков

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

Рабочая система: 1С 8.3.16.1063 + MSSQL 2012.

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

Исходные данные: регистр накопления (остатки) «Товары на складах» с измерениями «Склад, Номенклатура» и ресурсом «Количество».

Пишем простой запрос:

ВЫБРАТЬ
НАЧАЛОПЕРИОДА(ТоварыНаСкладахОстаткиИОбороты.Период, ДЕНЬ) КАК Период,
ТоварыНаСкладахОстаткиИОбороты.Номенклатура КАК Номенклатура,
СУММА(ТоварыНаСкладахОстаткиИОбороты.КоличествоНачальныйОстаток) КАК КоличествоНачальныйОстаток,
СУММА(ТоварыНаСкладахОстаткиИОбороты.КоличествоПриход) КАК КоличествоПриход,
СУММА(ТоварыНаСкладахОстаткиИОбороты.КоличествоРасход) КАК КоличествоРасход,
СУММА(ТоварыНаСкладахОстаткиИОбороты.КоличествоКонечныйОстаток) КАК КоличествоКонечныйОстаток
ИЗ
РегистрНакопления.ТоварыНаСкладах.ОстаткиИОбороты(&ДатаНачала, &ДатаОкончания, День, ДвиженияИГраницыПериода, ) КАК ТоварыНаСкладахОстаткиИОбороты
СГРУППИРОВАТЬ ПО
ТоварыНаСкладахОстаткиИОбороты.Номенклатура,
НАЧАЛОПЕРИОДА(ТоварыНаСкладахОстаткиИОбороты.Период, ДЕНЬ)

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

В итоге мы получаем таблицу с неверными данными — точнее, неправильными остатками. Опишу на примере. Вот исходная таблица регистра:

ДвижениеДатаСкладНоменклатураКоличество
Приход01.06.2020СК1Товар1100
Приход02.06.2020СК2Товар1200
Расход02.06.2020СК1Товар150
Расход03.06.2020СК2Товар1100
Вот такие простые исходные данные

Теперь мы выполняем наш запрос с указанием периода с 01.06.2020 по 04.06.2020 и на выходе получаем табличку с такими данными:

ДатаНоменклатураОст. нач.ПриходРасходОст. кон.
01.06.2020Товар101000100
02.06.2020Товар110020050250
03.06.2020Товар12000100100
04.06.2020Товар115000150
Вот такой результат

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

Будьте очень внимательны! Не наступайте на эти грабли!

Я на этот косяк (при выборке ежедневных остатков и движений) потратил 3 часа: на разбор полетов (поиск и выявление ошибки) и переделку алгоритма. Пришлось действовать по старинке — писать цикл со сборкой запроса «ОБЪЕДИНИТЬ», где в каждом подзапросе вытаскиваются остатки на одну дату. Так получилось дольше (по времени выполнения запроса), но зато данные верные.

Некоторые могут задаться вопросом — кому и на кой черт нужны остатки и движения с разбивкой по дням. Ответ — очень часто требуются такие данные для анализа товарных запасов, расчета автозаказа и, как ни странно, официальные представители больших контор требуют от дистрибьюторов данные о вторичных продажах и товарных запасов на складах и просят ежедневную выгрузку этих данных за последние 40 дней. А 1С подкладывает ОЧЕНЬ большую свинью с косяком в выполнении запроса.

На сегодня все. Дальше будет больше и интереснее.

Рубрики
1С 8.3 и не только

Программисты 1С — поиск и мучения (часть 2)

Теперь расскажу о втором виде программистов 1С — «продвинутые». Это отдельная когорта программистов, которые уже сделали шаг на вторую ступеньку и пытаются подняться выше, но…

2.1. «Продвинутые младшие». В большинстве случаев это люди возрастной категории — 23-30 лет и запросами по ЗП 40-45 килорублей. Успели поработать в одной-двух-трех компаниях, поднабрались небольшого опыта. Начинают понимать с чем имеют дело — основы учета, остатки, обороты, дополнительная информация. Умеют создавать отчеты, обработки, алгоритмы, где требуется получать информацию из нескольких таблиц. От таких сотрудников уже можно получать реальную отдачу в работе. Но, как и всегда есть и очень важный нюанс — надо в как можно более сжатые сроки оценить, что из себя представляют знания такого сотрудника — или это реальное понимание системы или это «зазубренное» знание. В первом случае — сотрудник будет развиваться, идти дальше и приносить все большую и большую пользу, а во втором — это предел. Дальше зубрить нечего и человек так и останется на данной ступени развития. Ради справедливости надо заметить, что в некоторых случаях (компаниях) есть необходимость иметь таких «роботов», выполняющих черновую работу. Поэтому выбор оставлять сотрудника или увольнять полностью лежит на руководителе подразделения. Именно руководитель должен обеспечивать «робота» работой или развить потенциал в понимающем сотруднике.

2.2. «Продвинутые понимающие». Это уже люди до 35 лет и запросами ЗП 50-60 тысяч рублей. На мой взгляд, одна из самых приятных в работе категория программистов. Они уже понимают что делать, как делать. Им не надо все описывать по шагам, говорить какие данные откуда брать — они сами это могут понять, посмотрев и разобравшись с конфигурацией. Основное внимание в работе с такими программистами надо уделять коду, который они создают. Зачастую написанный такими программистами код страдает необоснованно частыми переходами выполнения с клиента на сервер или изобилует излишними проверками условий и из-за этого выполняется дольше. Важно вовремя подсказать это, где-то подправить, оптимизировать и все будет работать как часики. И главное — помогать такому сотруднику развиться, создать условия для прямого общения с пользователями, которые пользуются плодами его труда, чтобы программист начал смотреть на создаваемый им интерфейс, отчеты с точки зрения пользователя и в дальнейшем уже мог предугадывать желания пользователей и сам решать, как и что должно выглядеть и работать, чтобы было удобно.

Рубрики
1С 8.3 и не только

Программисты 1С — поиск и мучения

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

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

1.1. «Начинающие младшие» — как правило, молодые люди 19-23 лет (иногда до 27), которые чем-то занимались, где-то кем-то работали и тут их осенило (а может посмотрели на зарплаты от 80к), что 1С — это то, о чем они мечтали. Они посмотрели видео курсы,  иногда честно отходили на какие-нибудь очные курсы, бывает даже, что читали книги типа Радченко. Запросы по ЗП у таких маленькие (в текущих ценах от 25 до 35 килорублей) и велик соблазн взять на работу, подучить месяц-два и получить какого-никакого программиста за относительно небольшие деньги. Что мы получаем — этот горе-программист кое-как может создать визуальную форму отчета/обработки, создать макет mxl, но когда дело доходит до написания кода, то сразу возникают сложности. Огромные. Начинаем выяснять, идем по шагам и делаем пугающий вывод — он не может составить алгоритм своих действий. Даже на листочке расписать по пунктам что и в какой последовательности делать не в состоянии описать. Доходит даже до умопомрачения — не может описать, как он добрался до работы (хотя бы вышел из дома, дошел до остановки, дождался нужного автобуса, доехал до нужной остановки и т.д.). О каком программировании идет речь? У меня ребенок в школе на уроках информатики составляет такие алгоритмы. Хорошо, что это выясняется легко и быстро, и уже на второй-третий день этот сотрудник уходит восвояси полностью провалив испытательный срок. На таких даже время тратить не стоит.

1.2. «Начинающие с опытом» — немного лучше, чем младшие. В основном молодые люди от 23-27 лет. Получили высшее образование (очень часто связанное с техникой, компьютерами, математикой). В основном уже успели поработать у франчей. Консультировали пользователей, дорабатывали типовые конфигурации (исправление отчетов, документов, печатных форм) по-мелочи. Запросы — 35-40к в месяц. За такие деньги мы получаем программиста, который может сделать печатную форму для документа (даже сам), простой отчет (типа вывести список). НО! Как только поручаешь ему немного более сложную задачу, где надо написать запрос с выбором данных из десятка таблиц, расчетом остатков и движений, то мы видим, что этот «программист» не знает предметную область — что такое остатки, движения, как они взаимосвязаны и из каких таблиц их получать. На такого кандидата я трачу времени побольше — 1-2 недели, пытаясь объяснить как ведется учет, как из записей регистра накопления получаются остатки, как соединятся таблицы в запросах, основные алгоритмы и принципы. Если человек начинает понимать то, что ему пытаются донести, то он даже может принести какую-нибудь пользу (написать несколько простых отчетов и печатных форм), но в большинстве случаев мы видим, что понять основы учета для такого программиста является непосильной задачей, у количество печатных форм ограничено и с сотрудником приходиться расставаться как с непрошедшим испытательный срок. Для таких «программистов» есть франчайзи и это их потолок — консультация, обновление типовых конфигураций и… печатные формы. Надо признать, что один из таких у меня продержался месяца два и для своего уровня сделал достаточное количество простых отчетов и злощастных печатных форм.

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

Рубрики
Ошибки в платформе 1С

Некорректное сравнение в запросе 1С

Этой статьей начинаю описание ошибок, выявленных в 1С в процессе работы. Ошибки странные, если не сказать больше.

Рабочая система: 1С 8.3.16.1063 + MSSQL 2012.

Ошибка в обработке условия в запросе.

Проблемный запрос:

ВЫБРАТЬ
СпрНоменклатура.Ссылка КАК Номенклатура,
РегистрПриоритет.Приоритет КАК Приоритет
ПОМЕСТИТЬ ВТ_Номенклатура 
ИЗ Справочник.Номенклатура КАК СпрНоменклатура 
ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ПриоритетыТоваров.СрезПоследних(&ДатаОкончания, ) КАК РегистрПриоритет
ПО (РегистрПриоритет.Номенклатура = СпрНоменклатура.Ссылка) И (ВЫБОР КОГДА РегистрПриоритет.ДатаОкончания = ДАТАВРЕМЯ(1, 1, 1) ТОГДА ИСТИНА ИНАЧЕ РегистрПриоритет.ДатаОкончания >= &ДатаОкончания КОНЕЦ) 
;
ВЫБРАТЬ
ВТ_Номенклатура.Номенклатура КАК Номенклатура,
ВТ_Номенклатура.Приоритет КАК Приоритет
ИЗ ВТ_Номенклатура КАК ВТ_Номенклатура
ГДЕ
ВТ_Номенклатура.Приоритет <> Значение(Перечисление.ВидыПриоритетов.Супер)

При выполнении этого запроса получается такая штука:

Ожидание: получить все записи, из справочника Номенклатура, у которых установлен приоритет, не равный значению «Супер» (в общем — записи из временной таблицы ВТ_Номенклатура, у которых приоритет равен пустой ссылке, NULL или любому значению кроме «Супер»).

Реальность: Получаем только те записи, у которых во временной таблице ВТ_Номенклатура поле «Приоритет» оказывается заполнено, т.е. значения NULL не попадают в итоговую таблицу, что очень странно, т.к. они не равны значению «Супер».

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

Рубрики
1С 8.3 и не только

Выбор: самописная или типовая конфигурация?

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

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

Плюсы:

  • «Уже все готово» — есть основные документы, отчеты и т.д.
  • Возможность регулярного обновления и не надо переживать за обновление регламентированных форм
  • Уже готовые обмены данными с другими учетными системами, сервисами и .т.д (бухгалтерия, сайты, ЭДО)

Минусы (рассматриваются именно из специфики нашей компании):

  • Требуется много (огромное количество) доработок под наши бизнес-процессы, многие из которых невозможно выполнить так, чтобы не потерять возможность «легкого» обновления.
  • Пользователи не умеют (на мой взгляд и не должны иметь возможность) использовать большой набор универсальных отчетов.
  • Огромное количество различных возможностей по ведению учета, из-за которых, в конечном итоге, начинаются торможения (по крайней мере на нашем оборудовании)

В итоге было принято решение взять за основу «Библиотеку стандартных подсистем», а все остальное писать самому (с помощниками), т.к. «готовые» решения подходят:

  • для «малого бизнеса» — когда у тебя 1-2-5 работников, 1-2-5 магазинов и нет «специфических» бизнес-процессов и ты работаешь не спеша в свое удовольствие.
  • для «большого бизнеса» — когда ты можешь потратить десятки-сотни миллионов денег на оборудование и доработку учетной системы
Рубрики
1С 8.3 и не только

Предисловие

Сегодня ровно 30 дней, как компания, в которой я работаю на должности начальника IT (и программиста 1С одновременно), совершила большой шаг — отложила в сторону старинную 1С7.7 и начала работать по-новому. Теперь цифры для нас считает 1С8.3.

Завершились долгие, почти 3 года, страдания-мучения написания новой конфигурации. Эта эпопея проходила с переменным успехом, программисты 1С приходили и уходили (я даже сбился со счета, сколько их было), но дело потихоньку продвигалось к своему завершению. К сожалению, до часа Х не дожил ни один из приходящих-уходящих программистов и мне пришлось в-одиночку внедрять новую платформу.

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

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

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

  • вид деятельности компании: оптовая и розничная торговля бытовой химией, товарами для дома, косметикой, парфюмерией
  • количество пользователей: 100+
  • количество активной номенклатуры: 20000+
  • количество документов: 2000+/в день
  • начальный размер базы данных при старте (переносились ТОЛЬКО документы по движению товаров и взаиморасчетов): 250+Гб

Если вас заинтересуют еще какие-нибудь параметры работы системы, спрашивайте, буду рад ответить и, надеюсь, это поможет вам не наступить на те грабли, на которые пришлось наступить мне.