0. vasvl123 94 19.10.16 19:37 Сейчас в теме

Адресная система хранения на складе

Решение тестового задания. Разбор ошибок.

Перейти к публикации

Комментарии
Избранное Подписка Сортировка: Древо
1. CheBurator 3399 22.10.16 16:07 Сейчас в теме
замечания проверяющего №3 - с точки зрения правильности/адекватности рабоыт - основное. для складской системы - это неуд. так что задача конечно выполнена, но... ;_)
2. vasvl123 94 22.10.16 17:04 Сейчас в теме
(1) CheBurator, перед записью документов производится контроль наличия мест / остатков
3. rpgshnik 1680 24.10.16 04:29 Сейчас в теме
А тестовое задание куда такое?
4. vasvl123 94 24.10.16 08:09 Сейчас в теме
(3) rpgshnik, участие в проектах разработки на платформе 1С 8.х опыт программирования на платформе 1С 8.х от 3х лет з/п до 60к
5. AlexO 127 15.12.18 16:04 Сейчас в теме
1. Не оптимальный алгоритм приемки - все данные вытаскиваем из базы и потом с ними работаем, вместо того, чтобы получить только необходимую информацию. Например, нужны только ячейки, в которых есть остатки по товарам из документа и пустые ячейки.
Спорный вопрос.
1С не имеет механизмов выборки-из-выборки в одном запросе (a la "выборка в окне" в SQL), потому что зачастую невозможно указать сразу все условия выборки, и требуется сначала получить "хоть что-то" (обычно это и есть "получить все" с минимально наложенными условиями - период, организация, etc), а уже потом "это все" анализируется, и, в зависимости от того, что попало в выборку, из этого "все" выбирается нужное. Причем, тут могут быть и последовательно три-четыре уровня отбор-выборка, а не два.
Применительно к Вашему примеру: это хорошо, если в нужном регистре (выборку по документам не рассматриваем - тут вообще не имеет смысла говорить о скорости, такая выборка сама по себе будет в разы тормозней любой "неоптимальности" наподобие "выборка всего") - есть поле "Регистратор" (можно сразу выбрать номенклатуру по документу).
А если нет? То что?
Совершенно верно - сначала выбираем всю номенклатуру, потом находим номенклатуру по документу, потом сравниваем результат 1-го запроса со вторым... Вот уже три разных запроса, с "выборкой всего". И будут они хоть вложенные, хоть пакетные, хоть отдельно - разница только в сортах тормозов.

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

3.Алгоритмы проведения построены так, что есть возможноСТЬ двум операторам произвести распределение В одну и ту же ячейку. Не используется блокировка в транзакции необходимого диапазона ресурсов.
Ну пусть бы сразу и объяснил, как он предполагал "заблокировать" ячейку при отсутствии в 1С блокировки отдельной записи (только всего регистра-таблицы), и отсутствия "уведомления" об апдейте записи тем, кто уже использует данные из неё в режиме чтения (т.е. запрос уже прочитал таблицу, "освободил" её, и ждет действий другого оператора).
Т.е. если один оператор успел прочитать, что ячейка пуста, а второй заблокировал и изменил запись (внес товар в ячейку), то кто виноват? Первый получил данные, что ячейка пуста, инициирует запрос на открытие и блокировку таблицы под запись, ждет окончание выполнения транзакции второго (с записью), подсоединяется, блокирует и уже сам и меняет состояние того же адреса другим содержимым.
То есть "проверяющий" посетовал на отсутствие механизма обратной связи? Ну извините, тут тогда целый дополнительный модуль проверок и противовесов еще писать надо.

4.Документ инвентаризация мог бы быть более эргономичным, например заполнить по остаткам учетной системы.
Ну, а при открытии программа могла бы сразу сообщать, что-где в документах-ячейках-регистрах недозаполнено, незабито, или не соответствует одно другому и требует перепроверки и контроля.
Но все это - расширение требований к системе, и дополнительные затраты на разработку. Ок, если "проверяющий" именно это и хотел сказать.

5.Структура регистров и справочников не оптимальная, при добавлении иной схемы адресации ячеек придется изменять 2 таблицы.
При добавлении "иной схемы адресации", скорей всего придется переделывать вообще всю структуру, а не "2 таблицы изменить", потому что "изменение адресации" - это изменение базовой методики и алгоритмов запроса и хранения.
С чего "проверяющий" взял, что только две таблицы? Он думает, что "добавление иной схемы адресации" - это оно везде у всех одинаково, и всегда содержит одни и те же "изменения"?

6.Не оптимальный алгоритм проведения уплотнения (в системе почему-то назван Перемещением). Опять получаем все данные из базы и потом в циклах пробегаем и ищем то, что нужно. Хотя нужно получить из базы только то, что необходимо уплотнять, т.е. где остаток меньше чем коэффициент паллетирования.
Интересно, а структура организации данных вообще позволяет сразу отобрать остаток, чтобы по нему можно было ориентироваться, сравнивать с коэффициентом, и принимать решение? Как-то странно "проверяющий" проверяет - сравнивает результат с неким своим шаблоном решения, как-будто для него - все БД одинаковы, с едиными таблицами, полями, и наполнением.
В итоге что.
Скажу, что попали вы - под обычный "поиск идеальности в шаблонности", когда оценивают по шаблонам и держат в голове уже свое готовое решение "идеальной задачи", а не конкретное решение конкретной задачи-проблемы.
Ну так пусть для начала создадут себе идеальную базу с идеальными пользователями, а уже потом и решают в ней свои идеальные задачи.
6. vasvl123 94 15.12.18 19:49 Сейчас в теме
(5)Спасибо за подробный разбор. Причина придирок проверяющего в том,
что вакансию они закрыли раньше, чем я сделал тестовое задание. В пятницу дали задание, а в воскресенье уже закрыли. Было обидно, да. Мне тогда работа нужна была очень, но судьба распорядилась иначе. Может оно и к лучшему. Я сейчас свой проект пилю, скоро планирую здесь опубликовать.
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Автор новостных обзоров на тему 1С и бухучета
Санкт-Петербург
По совместительству

Ведущий программист 1С
Санкт-Петербург
зарплата от 130 000 руб.
Полный день

Программист 1С
Москва
зарплата от 130 000 руб. до 200 000 руб.
Полный день

Бизнес-архитектор 1С, ведущий консультант
Санкт-Петербург
Полный день

Руководитель проектов 1С
Санкт-Петербург
Полный день