Константин Чилингаров: Может имеет отношение
Точно имеет.
Под подозрением задвоение работника в задании как раз.
Но тут трудно сказать точно. В т.ч. потому чт ...
Константин Чилингаров: написал:
Еще бы поиск допилить в обеспеченности по заказам, чтоб искал не только номер, но и материал
Будет. В ближайшем обновлении, на ...
Константин Чилингаров: Здравствуйте,
Я посмотрел Ваш ролик. Спасибо!
Только с обновлением это, по-моему, никак не связано.
Давайте поясню один момент:
...
Константин Чилингаров: Движок форума не разрешает напрямую Excel файлы в сообщения вставлять.
Ну ладно. Понятно, в общем, о чем речь.
на будущее: если нужно Excel фа ...
Константин Чилингаров: Тут ещё знаете, в чем может быть дело...
Не в размере даже, а во внутренностях конкретного файла с картинкой.
Ошибка может озвучиваться си ...
Константин Чилингаров: Здравствуйте,
Очень странная картина... Не сталкивались никогда с таким.
Копию базы данных можете дать нам посмотреть?
Если есть техни ...
Константин Чилингаров: Здравствуйте,
В этом окне, насколько я помню, сохраняется только список "постов" выбранных. При закрытии/открытии окна.
Порядок сл ...
Владимир Белов: написал:
Добрый день! Такой вопрос. Могу я установить базу данных на съемный диск и пользоваться на разных компьютерах - переставляя то ...
Константин Чилингаров: Здравствуйте,
Обычно, непосредственно с терминала выгружают управляющие программы какие-нибудь, к заданию, которое берется в работу. Н ...
Константин Чилингаров: К сожалению, проблема хронического отсутствия времени пока не позволила сделать.
Лежит заготовка под второй ролик с лета. Пока отложена ...
Константин Чилингаров: написал:
Честно говоря, "средний" уровень как-то никогда не рассматривали для работы.
Всё меняется...
10 лет назад там действитель ...
Константин Чилингаров: написал:
Можно, пожалуйста, выложить скрины, как это реализовано
Пожалуйста:
Рис.1 - Параметры в справочнике. Которые я использовал, ка ...
Константин Чилингаров: Здравствуйте!
Да, встречали такую ситуацию. Но, к сожалению, пока никак не можем научиться её стабильно повторять. Не можем пока найти к ...
- хотелось получить рекомендации, как вести выдачу инструмента/возврат сломанного инструмента. Выдача: 1) без привязки к заказу и 2) конкретному сотруднику. Вроде бы напрашивается схема "через требование без привязки к заказу", но у требования "получатель" - это подразделение, а не сотрудник. Что посоветуете?
Простой путь: Делаете "требование". Когда оформляете расход по нему, там есть специальное окно, где можно к расходу привязать конкретного работника (см. инструкцию, рис. 40). Потом по прошествии времени открываете окно Фактические затраты и группируете по колонке "С чем связано" (по фамилии работника). И будет статистика когда кому на сколько выдали (в деньгах). Можно посмотреть подробнее по документам, что именно выдали. Больше от такого упрощённого варианта ничего не добиться.
Сложный путь: В VOGBIT есть возможность точно так же, как для склада: - заводить свою "складскую" картотеку на каждого работника (что у него есть); - оформлять приход и расход на работника точно так же, как на склад.
Сама программа (платформа) такие вещи позволяет делать легко. А это значит можно: - оформлять передачу конкретного инструмента со склада на работника; - видеть остатки по работнику точно так же, как по складу (что есть, сколько, на какую сумму, полная история движения по каждой позиции); - оформлять передачу с работника обратно на склад, или в любое другое подразделение, или другому работнику, или "в никуда" (списание).
То есть, в принципе, в программе заложен инструментарий для организации полноценного учёта движения номенклатуры не только между подразделениями, но и между подразделениями и работниками. Если вы обратите внимание, то при ручном составлении учётного документа как раз выбирается тип получателя и поставщика - подразделение или работник. Единственное, в этой части не сделано каких-то специальных "упрощённых" пользовательских модулей типа Приход, Расход, Остатки на вкладке меню Складской учёт. То есть надо самому составлять учётные документы, заполнять спецификацию поставщика и получателя, карточки учётные, когда нужно, создавать. Муторно, может, несколько по сравнению с другими «однокнопочными» режимами, но если очень нужно, то вполне работоспособно.
Вот сделал за пару минут пример (см. картинку), используя штатные средства для работы с базой данных VOGBIT. Видно: - работника - остатки инструмента у него (что есть), количество (2 шт) - стоимость - историю движения (3 шт получил, 1 шт обратно сдал).
В принципе, возможна и разработка каких-то специальных интерфейсов для такого рода учёта (по типу модулей Приход, Расход, Остатки, Обороты), но:
1. Для начала, кому очень интересно, вполне можно попробовать и без каких-то спец. модулей, используя обычный "ручной" режим Учётные документы (как в моём примере). Может, местами и придётся чуть побольше кнопок понажимать, но задача то решается.
2. Интерес к развитию программы в этом направлении пока очень низкий. Последний раз одна организация, вроде как, хотела позаниматься такого рода детальным учётом инструмента года два назад. Но когда дело дошло до дела, они как-то расхотели…
Какой тип связи использовать, имеет значение только в том случае, если в дальнейшем эту информацию каким-либо образом использует какой-то из модулей программы. В данном случае - никакой пока никак не использует (по крайней мере из тех, что есть на сегодняшний день). Поэтому, по большому счёту, всё равно. Лично я бы, наверное, сделал так:
Для "передачи" (не важно, в какую сторону) завёл бы новый тип связи. Исходя из того, что сущность операции "передачи" несколько отличается от "расхода". А вот кто кому передаёт – это, по-моему, не так важно, если говорить о типе операции (типе связи). Как этот новый тип связи называть, в принципе, без разницы. Никакой программной обработки сейчас для него не предусмотрено. Если она и появится, то важен будет только уникальный идентификатор типа связи. А его, если что, можно и поменять в любой момент на нужный.
Для "расхода" (списания) я бы, пожалуй, использовал стандартный тип связи Расходная накладная (LT_Waybill_write_off), который применяется в модулях Складской учёт. По смыслу он, по-моему, вполне подходит.
По поводу "идеологического" смысла документов-оснований (расчётных документов):
Первое, что даёт наличие документа-основания, это возможность зафиксировать не только факт движения товарно-материальных ценностей, но и ещё до этого момента зафиксировать потребность, т.е. факт того, что движение нужно, и какое именно. Представьте, например, что вы хотите получить на складе инструмент, а его там нет в наличии. Его ещё нужно купить сначала и на склад положить, прежде чем взять. То есть никакого движения (учётных документов) пока ещё нет. Но записать где-то надо, чего и сколько требуется. Чтобы знать, чего не хватает, чего сколько покупать. Вот тут и помогает для этой цели документ-основание (лимитно-заборная карта, заявка, требование и т.п.).
Следующий этап - выдача со склада. Фактически выданное количество - понятно. Оно в расходной накладной (или аналогичном по смыслу учётном документе) написано. Сколько выдали - ясно. А много это или мало? Всё выдали, что нужно, или не всё? Или, может, наоборот, даже больше выдали, чем нужно? Чтобы это понять, надо знать не только, сколько выдали, но и сколько должны были выдать по плану. Чтобы было с чем сравнивать. Эта цифра (сколько было затребовано) опять же есть в документе-основании.
Ну и, наконец, наличие документа-основания значительно упрощает жизнь простому кладовщику. Я бы даже сказал, в корне меняет её (особенно при наличии соответствующих интерфейсов для работы, как, например, в модулях Складской учёт - Приход и Расход). Для примера, представьте себе выдачу со склада каких-нибудь электронных компонентов. По одной накладной за раз выдаётся наименований 150. Длинные-предлинные названия, половина из которых отличаются одной-двумя цифрами где-нибудь в середине. И номенклатура этих компонентов разных в базе этак тысяч 25. Представьте себе, как выгладит в такой ситуации составление вручную кладовщиком спецификации расходной накладной. Каждую позицию найти в базе, вставить, указать количество и т.д. Он вас проклянёт. Вручную написать накладную ручкой на бумаге быстрее. А при наличии документа-основания и правильно организованной работе с ним – ничего заполнять/составлять не надо вообще! Сразу есть готовая «рыба» расходной накладной. Список с количествами. Остаётся только по этому списку собрать всё и, если что, где-то цифры подправить (сколько реально выдал). И бумажку распечатать.
Это не то, что «лучше». Это качественно другой уровень жизни. В первом случае (составление накладной вручную без документа –основания) кладовщика вы обрекаете на ежедневные мучения. Вас, программу и компьютеры вообще он скоро будет искренне ненавидеть. Все остальные тоже получат в результате мало пользы. Ибо вводить данные он будет с большим запозданием, скорее всего, не все и при этом с кучей ошибок. При автоматизированном составлении расходной накладной по документу-основанию и правильно организованном процессе кладовщику программа помогает. Она облегчает его работу, упорядочивает. Плюс документы вручную составлять/оформлять не надо, они сами получаются. И все остальные имеют максимально достоверную, своевременную и точную картину, насколько это вообще возможно с учётом прочих факторов.
Резюме: С технической точки зрения, а также если в простейшем случае рассматривать только задачу контроля движения (инструмента или любых других товарно-материальных ценностей), расчётные документы (документы-основания), в принципе, не нужны. Если смотреть на проблему шире, то преимущества наличия документа-основания я вам привёл.