Да всё верно, это функции, но алгоритмами они называются, так как реализуют конкретную последовательность действий, например: поиск, сортировку, разбиение и т.д.
Насколько я смог раскопать, кодогенерацию используют только в связке с интерфейсами для создания «классических» мапперов. Возможно, я что-то упустил, но могу еще посоветовать другую статью, где некоторые аспекты освещены более подробно: https://code-maze.com/mapster-aspnetcore-introduction/
Составление отчета из отбора, допустим, 50 позиций номенклатуры — не считается признаком хаоса в учете. Этим часто занимаются бухгалтеры, когда необходимо посмотреть оборотно-сальдовую ведомость. И поскольку в бухгалтерии одним из важных инструментов является Excel, то удобно сформировать типовой отчет, загрузив значения для отбора непосредственно из Excel-документа.
Стоит учитывать тот момент, что 1С-системы могут отличаться, сочетая в себе несколько разных конфигураций. К примеру, справочник номенклатуры может иметь структуру не от бухгалтеров, а от производственников, поэтому может возникнуть необходимость в таких отборах. Также бухгалтер может только приступить к работе на предприятии, не успев обновить структуру справочников.
Кроме того большая часть отчетов построена на СКД.
Обработка в конфигурации «1С: Бухгалтерия предприятия 3.0» предназначена для таких типовых отчетов, как ОСВ, Обороты, Карточка счета и т.д. Разумеется, все они построены на СКД и обработка прекрасно работает с ними.
Есть более простые и удобные как для пользователя так и для программиста методы.
Поделитесь примерами? Описанный в статье способ решает простую, но довольно частую проблему, облегчая формирование отбора в стандартных бухгалтерских отчетах. Если вы знаете неручной способ, как загрузить отбор в отчет, пожалуйста, поделитесь.
Спасибо, что обратили внимание. У нас точно не было цели запутать читателей. Поэтому уточнили формулировку — речь идет именно о необлагаемом доходе. Подробный пример расчета такого налога приводим в посте.
Мы выносили большинство данных, которые могут меняться, в отдельные файлы, поэтому с минорной поддержкой могут справиться DevOps или разработчики клиента.
Но если на сервисе появятся новые сценарии, то понадобится сотрудник, который будет заниматься тестами. Лучше, если это будет не совмещающий разработчик, а отдельный SDET. Так задачи разработки и написания тестов будут идти параллельно, и проект реализуется быстрее.
то все просто — на момент разработки этого кода мы только начинали свое знакомство с электронными подписями и просто не знали об его существовании. Наше решение покрывало наши потребности, поэтому не было необходимости использовать что-то другое.
В 1С:ERP есть обширные возможности по работе не только складских, но и прочих процессов предприятия. Все происходит в одной системе, где обрабатываются данные и формируется отчетность. Перечисленные вами системы тоже удобны, но больше подойдут для управления в текущем моменте.
В нашей практике есть крупные компании, процессы которых в рамках складских операций 1С:ERP покрывал в полной мере. Когда они решили вести весь процесс компании в одной системе, возможности систем TMS, WMS, YMS оказались излишни.
Нашей целью было помочь разобраться, когда есть необходимость во внедрении системы 1С:ERP для оптимизации работы склада. Чтение технической документации требует определенных навыков использования 1С, и часто у сотрудников компаний на ее изучение не хватает достаточно времени. Поэтому мы рассмотрели основные особенности системы и возможные проблемы в кратком и доступном формате
Волшебного подхода не существует. Все сильно зависит от конкретной ситуации: проекта, решаемой задачи, располагаемого бюджета, самого клиента и его уровня понимания, что такое ML в целом. — Есть бизнесы, которые хорошо понимают специфику и готовы к тому, что очередной эксперимент может не дать результата. — Есть бизнесы, которые хотят получить продукт "под ключ" за фиксированный бюджет =)
Первое, что на наш взгляд стоит сделать — убедиться в том, что наш НИОКР имеет известное решение. То есть мы поймем, что пройти путь от точки А до точки Б возможно, останется вопрос — сколько трудозатрат потребует этот путь, и с какими рисками мы столкнемся на пути.
Далее начинаем итеративно идти к цели: в рамках одной итерации проверка 1-2 гипотезы и проведение эксперимента. Обозначаем, что хотим проверить, доносим до клиента и еще раз проговариваем, что гарантий результата нет, но даже не успешный эксперимент поможет нам осознать, что был выбран неверный подход к решению задачи. Выяснив это на ранних этапах, мы сможем сэкономить время и оперативно сменить подход к решению.
Также стоит погружать клиента в детали и нюансы ML-разработки, чтобы для него это был не просто черный ящик, а клиент сам понимал взаимосвязи между действиями команды и результатом, понимал сложность работы команды и самой задачи.
И еще важное — после каждой итерации обязательно нужно демонстрировать результаты для клиента.
Осмелимся предположить, что в нашем случае оценка задачи командой — это нажитый опытом хороший бонус сейчас на проекте. Команда к этому шла не один месяц, набивая себе шишки.
У нас на проекте подсчет ведется в человеко-днях. Можно перевести все на человеко-часы, подобные схемы есть. В нашей команде 20+ человек, а спринт длится месяц, поэтому проще посчитать человеко-дни (значения обычно на уровне 100+), а не человек-часы (их тогда будет 1000+).
Как правило, такого рода задачи — это составляющие более крупной задачи. В нашем бэклоге задач меньше 1 человеко-дня нет.
В целом этот вопрос на каждом проекте решается индивидуально в зависимости от того, кто будет пользоваться инструментом, насколько это удобно, какие фичи нужны конкретно, какие инструменты принято было использовать исторически. Некоторые считают Postman более удобным в использовании и установке, поэтому и выбор даже просто из-за этого фактора может лечь на него.
У нас на проекте более 300 запросов, поделенных на коллекции по продуктам, к которым запросы составлялись, и проблем с прогрузкой не возникало)
Документацию ведет и актуализирует один специалист, в нашем случае аналитик. На эту работу выделяется отдельная задача в спринте.
Выгружаем в GitLab, шарим ссылку на всех заинтересованных лиц.
У нас есть два варианта. Первый — инструкции по использованию коллекций для тех, у кого возникли по этому моменту вопросы. Второй — если нужно какой-то новый скрипт добавить и возникли затруднения, коллеги обращаются с вопросами к тем, у кого опыта в кодинге больше. Например, наш аналитик обращается за помощью к команде разработки или SDET-специалистам.
Основной смысл перехода в значительном снижении рисков. Основной риск в облаке — внезапное прекращение работы. Риск в on-premise — вероятное не обновление ПО. Такой риск сохраняется, но в данном случае принимается как допустимая плата за скорость побега из облака
Спасибо за ваше дополнение. Вы правы относительно ProofOfConcept и простых решений. Справедливости ради, это замечание нашло свое отражение в нашей третьей статье о Design Api First (https://habr.com/ru/companies/simbirsoft/articles/746020/). Рациональность и применимость той или иной методологии всегда стоит рассматривать в контексте вашей ситуации. Для нас ее применение обосновано как минимум по двум причинам: разработка итеративна — в контракт вносятся изменения, команды Backend и Frontend работают параллельно
Да всё верно, это функции, но алгоритмами они называются, так как реализуют конкретную последовательность действий, например: поиск, сортировку, разбиение и т.д.
Спасибо за замечание! Добавил еще один раздел с примерами поинтереснее)
Насколько я смог раскопать, кодогенерацию используют только в связке с интерфейсами для создания «классических» мапперов. Возможно, я что-то упустил, но могу еще посоветовать другую статью, где некоторые аспекты освещены более подробно: https://code-maze.com/mapster-aspnetcore-introduction/
Спасибо за примечание! Добавил в статью
Наличие такие отборов признак хаоса в учете.
Составление отчета из отбора, допустим, 50 позиций номенклатуры — не считается признаком хаоса в учете. Этим часто занимаются бухгалтеры, когда необходимо посмотреть оборотно-сальдовую ведомость. И поскольку в бухгалтерии одним из важных инструментов является Excel, то удобно сформировать типовой отчет, загрузив значения для отбора непосредственно из Excel-документа.
Стоит учитывать тот момент, что 1С-системы могут отличаться, сочетая в себе несколько разных конфигураций. К примеру, справочник номенклатуры может иметь структуру не от бухгалтеров, а от производственников, поэтому может возникнуть необходимость в таких отборах. Также бухгалтер может только приступить к работе на предприятии, не успев обновить структуру справочников.
Кроме того большая часть отчетов построена на СКД.
Обработка в конфигурации «1С: Бухгалтерия предприятия 3.0» предназначена для таких типовых отчетов, как ОСВ, Обороты, Карточка счета и т.д. Разумеется, все они построены на СКД и обработка прекрасно работает с ними.
Есть более простые и удобные как для пользователя так и для программиста методы.
Поделитесь примерами? Описанный в статье способ решает простую, но довольно частую проблему, облегчая формирование отбора в стандартных бухгалтерских отчетах. Если вы знаете неручной способ, как загрузить отбор в отчет, пожалуйста, поделитесь.
Спасибо, что обратили внимание. У нас точно не было цели запутать читателей. Поэтому уточнили формулировку — речь идет именно о необлагаемом доходе. Подробный пример расчета такого налога приводим в посте.
Мы выносили большинство данных, которые могут меняться, в отдельные файлы, поэтому с минорной поддержкой могут справиться DevOps или разработчики клиента.
Но если на сервисе появятся новые сценарии, то понадобится сотрудник, который будет заниматься тестами. Лучше, если это будет не совмещающий разработчик, а отдельный SDET. Так задачи разработки и написания тестов будут идти параллельно, и проект реализуется быстрее.
Истинно быль) Конечно, у нас по процессам обязательна полная передача всего кода и документации при завершении работ, так было и здесь
Если вы говорите про этот метод:
x500name.getRDN()то все просто — на момент разработки этого кода мы только начинали свое знакомство с электронными подписями и просто не знали об его существовании. Наше решение покрывало наши потребности, поэтому не было необходимости использовать что-то другое.
А вообще соглашусь, что, например, через
x500name.getRDNs(BCStyle.SURNAME)получать фамилию проще
В 1С:ERP есть обширные возможности по работе не только складских, но и прочих процессов предприятия. Все происходит в одной системе, где обрабатываются данные и формируется отчетность. Перечисленные вами системы тоже удобны, но больше подойдут для управления в текущем моменте.
В нашей практике есть крупные компании, процессы которых в рамках складских операций 1С:ERP покрывал в полной мере. Когда они решили вести весь процесс компании в одной системе, возможности систем TMS, WMS, YMS оказались излишни.
Нашей целью было помочь разобраться, когда есть необходимость во внедрении системы 1С:ERP для оптимизации работы склада. Чтение технической документации требует определенных навыков использования 1С, и часто у сотрудников компаний на ее изучение не хватает достаточно времени. Поэтому мы рассмотрели основные особенности системы и возможные проблемы в кратком и доступном формате
Спасибо за отклик!
Волшебного подхода не существует. Все сильно зависит от конкретной ситуации: проекта, решаемой задачи, располагаемого бюджета, самого клиента и его уровня понимания, что такое ML в целом.
— Есть бизнесы, которые хорошо понимают специфику и готовы к тому, что очередной эксперимент может не дать результата.
— Есть бизнесы, которые хотят получить продукт "под ключ" за фиксированный бюджет =)
Первое, что на наш взгляд стоит сделать — убедиться в том, что наш НИОКР имеет известное решение. То есть мы поймем, что пройти путь от точки А до точки Б возможно, останется вопрос — сколько трудозатрат потребует этот путь, и с какими рисками мы столкнемся на пути.
Далее начинаем итеративно идти к цели: в рамках одной итерации проверка 1-2 гипотезы и проведение эксперимента. Обозначаем, что хотим проверить, доносим до клиента и еще раз проговариваем, что гарантий результата нет, но даже не успешный эксперимент поможет нам осознать, что был выбран неверный подход к решению задачи. Выяснив это на ранних этапах, мы сможем сэкономить время и оперативно сменить подход к решению.
Также стоит погружать клиента в детали и нюансы ML-разработки, чтобы для него это был не просто черный ящик, а клиент сам понимал взаимосвязи между действиями команды и результатом, понимал сложность работы команды и самой задачи.
И еще важное — после каждой итерации обязательно нужно демонстрировать результаты для клиента.
Оценивать задачи и набирать их в бэклог вы можете любым удобным для вас методом)
Осмелимся предположить, что в нашем случае оценка задачи командой — это нажитый опытом хороший бонус сейчас на проекте. Команда к этому шла не один месяц, набивая себе шишки.
У нас на проекте подсчет ведется в человеко-днях. Можно перевести все на человеко-часы, подобные схемы есть. В нашей команде 20+ человек, а спринт длится месяц, поэтому проще посчитать человеко-дни (значения обычно на уровне 100+), а не человек-часы (их тогда будет 1000+).
Как правило, такого рода задачи — это составляющие более крупной задачи. В нашем бэклоге задач меньше 1 человеко-дня нет.
Описание разницы Swagger и Postman тянет на отдельную статью (например,
здесь https://apidog.com/articles/postman-vs-swagger/#limitations-of-postman-and-swagger).
В целом этот вопрос на каждом проекте решается индивидуально в зависимости от того, кто будет пользоваться инструментом, насколько это удобно, какие фичи нужны конкретно, какие инструменты принято было использовать исторически. Некоторые считают Postman более удобным в использовании и установке, поэтому и выбор даже просто из-за этого фактора может лечь на него.
У нас на проекте более 300 запросов, поделенных на коллекции по продуктам, к которым запросы составлялись, и проблем с прогрузкой не возникало)
Спасибо за отклик!
Документацию ведет и актуализирует один специалист, в нашем случае аналитик. На эту работу выделяется отдельная задача в спринте.
Выгружаем в GitLab, шарим ссылку на всех заинтересованных лиц.
У нас есть два варианта. Первый — инструкции по использованию коллекций для тех, у кого возникли по этому моменту вопросы. Второй — если нужно какой-то новый скрипт добавить и возникли затруднения, коллеги обращаются с вопросами к тем, у кого опыта в кодинге больше. Например, наш аналитик обращается за помощью к команде разработки или SDET-специалистам.
Спасибо за внимательность, поправили
Основной смысл перехода в значительном снижении рисков. Основной риск в облаке — внезапное прекращение работы. Риск в on-premise — вероятное не обновление ПО. Такой риск сохраняется, но в данном случае принимается как допустимая плата за скорость побега из облака
Спасибо за ваше дополнение. Вы правы относительно ProofOfConcept и простых решений. Справедливости ради, это замечание нашло свое отражение в нашей третьей статье о Design Api First (https://habr.com/ru/companies/simbirsoft/articles/746020/). Рациональность и применимость той или иной методологии всегда стоит рассматривать в контексте вашей ситуации. Для нас ее применение обосновано как минимум по двум причинам: разработка итеративна — в контракт вносятся изменения, команды Backend и Frontend работают параллельно