Антонов Антон

115
Рейтинг

monkbest
Антон Антонов



  •   Регистрация: 12.09.2012 (11 лет назад)

  •   Был(а) на сайте: 21.03.2024

Друзья
  • Чепа Чепа
  • Дмитрий Малышев
  • Евгений Комиссаров
Подписчики 7
Группы

Профессиональный разработчик

Рейтинг 115

История развития 1С:Торговли, что изменилось в архитектуре учета торговых и складских операций за 15 лет
+74 –2

Статья Для всех Платформа 1С v8.3 Оптовая торговля, дистрибуция, логистика Россия Управленческий учет Бесплатно (free) Нет файла Инструкции пользователю Оптовая торговля Розничная торговля Логистика, склад и ТМЦ Ценообразование, анализ цен

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

23.04.2018    26345    monkbest    61       

72

Корректировка движений существующего документа на управляемых формах
+7 –

Инструменты и обработки Для всех Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m) Внешняя обработка (ert,epf) Корректировка данных

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

1 стартмани

10.02.2016    10831    121    monkbest    3       

7

Как в ЗУП 3.0 правильно получить тариф/оклад по сотруднику
+37 –1

Статья Программист Сложные периодические расчеты 1С:Зарплата и Управление Персоналом 3.x Бухгалтерский учет Управленческий учет Бесплатно (free) Нет файла Зарплата Запросы

Речь пойдет о том, как в новой редакции получить тариф/оклад сотрудника на заданную дату. Этот самый тариф нам очень часто нужен для вывода в отчетах чисто информативно. Проблема в том, что в 1С ЗУП 3.0 не очевидно, какое из плановых начислений является основным.

06.02.2015    45889    monkbest    27       

36
Смотреть все

Комментарии

Dev › Запрос 1С copilot › #11 17.01.24 11:19
API ключи есть в обработке?
Публикации › Конфигурация "Планирование времени" › #9 18.08.23 9:34
(8)
(8) наверное пользуются, поделиться не могу, за эти годы уже сменил место работы
Публикации › 5 подходов при доработке конфигурации 1С, чтобы в будущем не было мучительно больно её обновлять › #26 15.08.23 10:17
(23)
На первый взгляд да, но...
1. Еще раз повторюсь про повторную доработку. Этот подход породит комментарии в комментарии
2. Код в комментарии никто не будет обновлять. Т.е. в обновлении "аутентичный" код изменился, а в комментарии кто его будет поддерживать?
3. В комментарии все зеленое, там нет подсветки синтаксиса, читать это - вырви глаз, быстрее в конфе поддержки без сравнения открыть этот модуль и процедуру и почитать с подсветкой, чем обучить свой мозг читать одноцветный код.

и еще много других минусов...
я не претендую на гуру и некоторые вещи могу криво излагать, поэтому и предложил ознакомиться с книжкой, там автор долго и со вкусом на протяжении сотен страниц разжевывает тему. Он там специально, чтобы книжка получилось книжкой, а не 10 строчек с правилами, много воды переливает из угла в угол, но зато доступно и понятно, сомнений не остается. После применения его постулатов читать свой собственный код спустя 5 лет в разы проще
Публикации › 5 подходов при доработке конфигурации 1С, чтобы в будущем не было мучительно больно её обновлять › #19 14.08.23 15:54
(6) поможет конечно, но её же надо запускать, а это время. И не дай бог изменения серьезные, если разработку считай с нуля надо делать, то скорость разработки в расширении в разы медленнее
Публикации › 5 подходов при доработке конфигурации 1С, чтобы в будущем не было мучительно больно её обновлять › #18 14.08.23 15:51
(5)
что-то не вяжется
1. доработка в конфе:
1.1 в обновлении модуль не затронут - затраты обновляющего = 0 секунд на модуль
1.2 модуль затронут - мы в сравнении сразу видим степень изменений, обновляющий принимает решение по процедурно, фиксирует принятые решения и тратит время на объединение.
2. доработка в расширении
2.1 в обновлении модуль не затронут - затраты обновляющего = 0 секунд на модуль
2.2 модуль затронут - затраты обновляющего = 0 секунд на модуль, но потом без возможности быстро сопоставить доработанный код с типовым, копируя тексты в блокнотик, запуская сторонние кадифы и еще черти что он тратит времени больше чем в пункте 1.2
Публикации › 5 подходов при доработке конфигурации 1С, чтобы в будущем не было мучительно больно её обновлять › #9 12.08.23 7:05
(7) только в отдельном так трекере! Ещё раз повторюсь, простыни мешают читать код. А толку от комментариев к коду, который изменили более одного раза нет. Вместо слов за слэшами напишите красиво и аккуратно, с нормальными именами переменных именами функций и пр
Публикации › 5 подходов при доработке конфигурации 1С, чтобы в будущем не было мучительно больно её обновлять › #4 11.08.23 11:32
(1) мне нравится следующая позиция: расширения только для hotfix. Сама 1С так их и использует. Это миф, что их придумали для "модульности".
Вот минусы разработки в расширениях:
1) Как ты проанализируешь доработки, если их нет в конфе? доработку в конфе я могу проанализировать запустив сравнение с конфой поддержки. расширение - только сохранять в текстовички.
2) просто прочитав текст модуля я не могу предсказать поведение программы, без отладки я не узнаю, что эта процедура модифицированная
3) при обновлении ты не отменяешь анализ, а откладываешь его и усложняешь. Автор обновления лихо его ставит, а с расширением пусть мучается кто-то другой, я обнову поставил, остальное меня не интересует.
4) могут отключиться и пользователь начнет заносить данные без логики в расширении. только разраб или админ правильно среагирует на сообщение "расширение1 неактивно"
Публикации › 5 подходов при доработке конфигурации 1С, чтобы в будущем не было мучительно больно её обновлять › #3 11.08.23 11:19
Цитата
Если код модифицируется или удаляется, то исходный типовой код должен быть сохранен в виде комментария, а не просто удален или изменен.
вот это плохой совет, так часто делают молодые коллективы
1) в сравнении вы не увидите остатков старого кода
2) читать код станет не удобно. Читаем читаем, стоп скроли три экрана, читаем дальше, так а эта переменная чему равна , скролим три экрана обратно... а это соседние строчки по сути.
3) пользы нет никакой, типовой код всегда можно найти в конфигурации поддержки, так еще и сравнение с ней запустить
4) что ты будешь делать, когда понадобится дорабатывать доработанное? Добавим еще три экрана закомментированного кода! Комментарии в комментариях.

Я знаю о чем говорю, часто встречал простыни нечитабельного кода, а потом удалял все эти "здесь был Вася" и остается 10 строчек понятной красоты. Все доработки и так видно при сравнении, а кто их когда делал смотрите в системе контроля версий (Git или хранилище)

Ну и в целом, читаем классику Роберта С. Мартина и понимаем, что комментарии зло в целом. Кроме написания ФИО автора, даты и номера таска - остальные комментарии от импотенции автора кода. Пишите такой код, который понятен без посторонних сочинений на вольную тему.
Dev › Git + 1С. Часть 2. Реализация Git workflow в 1С-разработке по шагам › #35 04.07.23 15:03
(34) стек простой - 1С, т.е. Конфигуратор+Хранилище или просто Конфигуратор
есть несколько ЗУПов на каждый филиал, все очень "крепко перепаханы", в большинстве своем одинаково, но есть отличия
надо оперативно ставить обновления, делать новые доработки и вычищать устаревшие

нравится как в GIT можно анализировать версии и связать комиты с задачами, но вижу только следующую схему:
по ночам со всех баз выгружаем в файлы конфу/внешние обработки/расширения. Дальше все изменения кто-то разгребает и фиксирует, кто-что и зачем и пушит в репозиторий. Т.е. такой "посмертный" учет разработки.
Разработка и обновления продолжить делать стандартно.

Было бы круто иметь на каждую рабочую базу свою ветку, ветку вендора и возможность отправлять доработку в несколько выбранных рабочих веток. При обновлении мы просто ставим в типовую базу обновление и отправляем 1000 изменей во все рабочие ветки. Потом собираем конфу для рабочей базы.
Dev › Git + 1С. Часть 2. Реализация Git workflow в 1С-разработке по шагам › #33 04.07.23 7:47
Читаю статью за статьей про GIT, EDT... никак не найду примера "реальной работы", все рассказывают про какие-то доработки одной обработки/модуля на проекте с 10+ разработчиками и при этом упоминают ERP.
В реальности доработанных объектов сотни или тысячи и пару раз в месяц выходит обновление от вендора, которое добавляет тысячи изменений в еще не доработанные объекты и в уже доработанные, если все это мержить сторонним софтом, то потом cf может и вообще не собраться, а может быть потеря данных из-за смены GUIDа объекта.
И вот тут и хочется услышать о подходах, как вести ветку vendor, как соединять vendor с develop?
Что разработка, что поддержка без регулярного получения изменений от вендора - МИФЫ ДРЕВНЕЙ ГРЕЦИИ. Если пол года не обновляться, потом ощутимую долю доработок придется делать чуть ли не заново.
Это основное отличие 1С от другого софта - объем изменений от самой 1С. Это и есть причина "глюков" и "мучений" пользователей и разработчиков. В другом софте люди фиксируют релиз, который есть сейчас и с ним живут до следующего внедрения лет 10, внося только личные правки.