Да всё верно, это функции, но алгоритмами они называются, так как реализуют конкретную последовательность действий, например: поиск, сортировку, разбиение и т.д.
Насколько я смог раскопать, кодогенерацию используют только в связке с интерфейсами для создания «классических» мапперов. Возможно, я что-то упустил, но могу еще посоветовать другую статью, где некоторые аспекты освещены более подробно: 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 — вероятное не обновление ПО. Такой риск сохраняется, но в данном случае принимается как допустимая плата за скорость побега из облака
Спасибо, хорошая тема, согласны)
Да всё верно, это функции, но алгоритмами они называются, так как реализуют конкретную последовательность действий, например: поиск, сортировку, разбиение и т.д.
Спасибо за замечание! Добавил еще один раздел с примерами поинтереснее)
Насколько я смог раскопать, кодогенерацию используют только в связке с интерфейсами для создания «классических» мапперов. Возможно, я что-то упустил, но могу еще посоветовать другую статью, где некоторые аспекты освещены более подробно: 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 — вероятное не обновление ПО. Такой риск сохраняется, но в данном случае принимается как допустимая плата за скорость побега из облака