Учёт материалов

Никаким образом.
С нашей точки зрения такая функциональность бессмысленна.

Это вы зря. Если заранее заложена технология изготовления определенного изделия и я выдал задание на его производство, то следовательно данный материал и будет израсходован с точностью до раскроя. Дело в том, что мы работаем на заказах и каждый раз абсолютно новые изделия. Материал мы закупаем соответственно на данный проект и отчитываемся по нему, а не по складу, т.е. склад практически обнуляется после каждого проекта. Я долго работал с 1С-кой - в ней это все практически выполняется: формируется документ, списываются материалы (как пример производство салатов в гипермаркете). Очень удобно - не надо парится: создавать ЛЗК, требования. Если данный функционал сделать, то в конце каждого проекта я просто бы создал требование на остатки и обнулил склад. Все!!!

А учет будет довольно точный, поясняю:
- есть цифры: материал_проект
             поступивший_материал
             материал_по раскрою
В базе:  материал_проект
        поступивший_материал
прогнозируемые остатки= поступивший_материал- материал_проект
реальные остатки= поступивший_материал-материал_по раскрою
прогнозируемые остатки/реальные остатки=опр. коэф. если он рамках, то все нормально и я списываю остатки со склада( потери по раскрою), если нет то начинаются разборки... из-за чего перерасход.

вот это самое интересное место. Откуда у вас эта цифра? Как именно и в какой момент вы её получаете?

Заодно подскажите, как в справочник номенклатуры добавить колонки параметры (например параметры длина и ширина)

Я не про это.

Это в общепринятой технической терминологии называется "размеры заготовки (детали)" и "норма расхода материала". То, что это вещи разные - это понятно изначально.

Вопрос был в другом.

Откуда цифра 1.75 ?
Почему именно 1.75 ? А не, например 1,77 или 1,59 ? Откуда вы её узнали? И в какой момент вы узнали, что именно 1,75 ?

Из программы раскроя

При ближайшем рассмотрении получается, что уже реализованный в VOGBIT принцип тоже хорошо подойдёт. Он даже лучше, чем предлагаемый альтернативный вариант.

Это есть. Режим Расчёт потребности (Документация, Ролик). Сколько надо материала по проекту знаем.
Ничего трудоёмкого нет. Нажали кнопку Расчёт потребности, нажали кнопку Сформировать документы. Готово. Список  «проект» есть.

С этим тоже всё понятно. Режим Складской учёт – Приход  (Документация, Ролик). Купили материал, получили, внесли. От этого всё равно никуда не деться, если хотите учёт вести. То, что пришло, хоть как придётся вводить*.
Таким образом "поступивший материал" тоже есть.

Дальше технология следующая:

Цифра с реальным количеством материала с учётом раскроя под конкретное задание, вы говорите, у вас есть.
Отлично!
Запускаем Складской учёт – Расход. Вводим номер заявки (лимитно-забоной карты), открывается общий список материалов для соответствующего заказа.
В колонку Выдаётся (вот здесь, рис. 37) вводим вашу цифру (ну всё равно же её куда-то надо вводить… ведь так?)
Это и есть цифра, сколько реально выдаётся.
Нажимаем Выдать – всё, материал ушёл, со склада списался.

Далее:
В любой интересующий вас момент (хоть по окончании заказа, хоть в процессе) запускаем режим Затраты план-факт (документация, скриншот). И видим там три колонки:

- Нормативная потребность - по вашему «проект»
- Затребовано - такого в вашей логике не предусмотрено. Это на случай, например, что по факту могут выдать вообще другой материал, не тот, который по нормативам. В вашем случае будет = Нормативная потребность.
- Выдано - по вашему «раскрой»

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

Вводятся ровно те же самые цифры, которые вы и так хотели вводить («поступление» и «раскрой» - он же «расход»). Но при этом нет никаких виртуальных списаний, прогнозируемых остатков и т.п. Зачем они?
Есть реальный учёт. Сколько пришло, сколько ушло. Есть соответствие того, сколько планировали по нормам и сколько в итоге на самом деле потратили. Есть остатки реальные текущие.

Имеем в полном объёме.

Тем проще.

Резюме:

1. В «автоматическом списании» необходимости никакой не вижу. Описанная выше технология работы все обозначенные задачи решает. Но при этом она проще, не имеет лишних промежуточных  шагов и даёт лучшие результаты.

2. Над чем можно было бы, в принципе, поработать во всей этой цепочке, так это разве что над какой-нибудь автоматизацией оформления поступления материалов. Идеи есть. Можем позаниматься, если интересно. Не бесплатно.

*В своё время обсуждался вопрос, сделать для тех, кто покупает материал всегда строго по заявке, некоторый модуль дополнительный, чтобы при приходе не руками вводить, что и сколько пришло, а брать за основу список из заявки и только количество проставлять и цену (вроде, как в Расходе сейчас сделано). Такую штуку сделать, в принципе, можно. Но за отсутствием платёжеспособного спроса пока данное пожелание лежит в разделе, как «отложенное до лучших времён».

Вы меня убедили, НО меня напрягает то, что сначала нужно создать ЛЗК или требование, потом на его основе создать расходный документ (списать со склада). Можно ли тогда как в 1С-ке прописать обработку - при создании задания предлагалось бы сразу создать расходный документ, где были бы прописаны все позиции материалов которые используются в данном задании. В этом случае я следуя вашей железной логике просто бы подставил бы реальные значения количества материалов исходя из своих расчетов.
  В этом бы случае не было бы этой многоходовки: требование - создание документа(на основании требования) - заполнение документа.
В моем случае создание требования "лишний ход". Время и путаница.
  Дело в том, что в нашем случае я выдаю задания на участки на определенный материал, а именно:
- гильотина - Лист10
- Пила      - Уголок 100х100 (как пример)
Соответственно и расходный документ создавался бы на эти материалы, при чем в одну строчку: Лист10 - 3т.
Вот тогда все было бы красиво.

Технически всё можно. Но лучше делать не так.
Если делать строго так, то в одном месте, в одном частном случае, улучшим, но в 10 других сделаем этим хуже.
Есть другой вариант, как можно сделать. С точки зрения универсальности намного более правильный. А в плане использования от вашего будет отличаться на 2-3 нажатия на кнопку мышки.

В общем, смысл понятен, в каком месте можно улучшать. В рамках платной поддержки можем позаниматься.

Вы не поняли вопрос. Я сам "кодерю по-малу". Вы можете обьяснить как самому написать макрос и где находятся модули обработок определенных режимов. В 1С-ке я этим занимался. Не думаю, что здесь слолжнее.

Здесь не тот случай.

Что касается кастомизации, то самостоятельно можно, например, сделать какой-нибудь свой простенький расчёт чего-нибудь по спецификации. Можно импорт какой-нибудь сварганить, чтобы создавались в базе автоматом номенклатура, спецификации и т.п. Дальше "по-малу" заканчивается.
Режимы типа График производства, Себестоимость, Обеспеченность и т.д. слишком сложны с точки зрения внутреннего устройства, чтобы там можно было по-простому что-то самому доработать.

В VOGBIT нет никакого своего встроенного языка программирования. Мы не стали изобретать велосипед. Если хотим программировать, то берём C#, Visual Studio и вперёд. Пишем свой плагин.

Известная тема…  

Только не вижу в этом смысла, если только у вас не вообще один заказ или не физически разделённые склады под каждый проект.

В такой постановке вопросы любит ставить бухгалтерия. Не вдаваясь при этом, обычно, в 2 нюанса: зачем это именно так нужно, и как предлагается на практике это организовать?

А практическая реализация такого подхода грозит наживанием себе большой и регулярной головной боли. Например:

1. Надо на заказ «А» 170 кг металла, а на заказ «Б» 213 кг. Купили 435 кг, ибо так продавалось. Как будем учитывать? Какой остаток по какому заказу?

2. Заказ «Б» пару дней может и подождать. Но есть срочный заказ «Ё». А металл дополнительный, который в этой связи понадобился, привезут в лучшем случае завтра. Что делать будем? Так то, по уму, металл то есть.  Можно просто сегодня спокойно порезать детали заказа «Ё», а завтра, когда ещё металл привезут, дорезать детали от заказа «Б». И всё бы было отлично.
Но у нас же металл строго по заказам! Что делать будем?
Ждать?
Или будем «передавать» металл  с заказа на заказ...
А не замучаетесь, если заказов будет не 3, а к примеру 18? Не устанете виртуально перетасовывать там между ними «остатки по конкретному заказу».

3. Заказ "А". кончился, заказы "Б" и "Ё" в работе, металл "по заказу А" остался. Что с ним делать? Куда его?

4. и т.д.

Корень зла ровно тот же, что и в идее «виртуального автоматического списания со склада по нормативам». Предлагается зачем-то описывать в программе некие действия и понятия,  которых на самом деле не существует. В реальности есть склад. Один. Есть приход, есть расход, есть остаток. А отдельно «склада заказа А» и "склада заказа Б" нет. Не существует его. Попытка в программе «сделать вид», как будто этот «склад заказа» есть, приводит в итоге только к каким-то непонятным действиям, которые вне программы выглядят совершенно бессмысленными.

И самое главное – для чего?

Ведь имеется:

1. «Обеспеченность» - Там видно, хватает ли того металла, что есть, на всё то, что надо сделать. Или не хватает. Или наоборот, даже лишний есть.

2. «Обороты» - Там видно, сколько за период всего купили металла, сколько всего потратили и сколько в итоге осталось. Плюс есть расшифровка, на что потратили – сколько ушло на какой заказ.

3. «Фактические затраты» - Там расписано на конкретный заказ, сколько итого на него потратили. И есть расшифровка, чего именно.

4. «Затраты план-факт» - там видно, насколько расчёты по нормативам в итоге совпали с тем, что реально потратили.

Почему этого не достаточно?
Зачем нужен некий виртуальный остаток по конкретному  заказу, которого на самом деле нет?

Особняком, правда, в этой истории стоит ситуация, когда заказы действительно физически делаются абсолютно отдельно друг от друга. И материалы под эти заказы физически покупаются отдельно. И хранятся физически в разных совершенно местах. Тогда понятно. Но в таком случае решается очень просто:

Вариант 1 - заводите кучу складов и ведите учёт на них отдельно. Имеет смысл, если реально всё хранится строго отдельно на каждый заказ (физически отдельно).

Вариант 2 – заводите вообще под каждый новый проект новую БД VOGBIT. Имеет смысл для огромных и разовых проектов. Когда каждый следующий – вообще новая жизнь.