Там либо получается глобально перерабатывать блок формирования цен/себестоимости, включая интерфейс оборудования/операций... либо, какие-то неудобные и извращенные решения получаются, пусть относительно быстрореализуемые... 

Продолжаем думать.

В общем мы не считаем ситуация с необновляемыми при повторном импорте ценами ценами ошибкой. 

Обсудил с технологом трудоемкость решения. Ответ: 2 ч/часа. Результат работы - SQL-процедура, которую необходимо будет выполнить на сервере и логика будет работать как нужно. 

• Есть типы клиентов, которые при получении продукции должны предъявлять доверенность
• Есть типы клиентов, которым отгружаем без доверенности
• Есть доверенности разовые с указанием ТМЦ
• Есть доверенности "открытые", выданные на период
• Есть те, кто приезжает с печатью или привозит заранее пропечатанные+подписанные документы, которым мы так же "верим"

Следом за этим клиентом приходит "розничный товарисч"... Для отгрузки ему менеджер должен понять, что это персонаж розничный и ему можно отгружать без доверенности... и более того - то же самое должна определить программа на основе, например, типа контрагента "Физ.лицо"... В целом вариант... 

И тут появляется самолично директор какой-нить фирмы со своей подписью и печатью. Что бы отгрузить, у него в карточке должно стоять - галочка "есть доверенность" или ориентироваться по признаку "главное лицо"?

Это всё к чему я? К тому что самая простая ситуация, когда на контактное лицо "вешается" признак наличия открытой доверенности на получения ТМЦ без ограничения по списку на период. Но в случае с разовыми доверенностями, с розницей и в ситуациях когда отгрузить все равно надо, то алгоритм меняется. И разумнее было бы сделать ограничение не жестким, а уведомительным - просто сообщение менеджеру "Про доверенность ничего не знаю! Всё равно продолжаем?" Да/Нет Такой вариант поможет снизить забывчивость пользователя и фактор человеческой ошибки - это плюс... И слегка затормозит работу - это минус... 

Ваши предложения? 

наверное Вы правы.

Поставлю в очередь девелоперам с более высоким приоритетом.

Варианты решения для обсуждения разместим здесь.

Запускаем Конфигуратор под логином sa

В дереве классов находим Склад. Поступления

далее

Далее

теперь надо задать условие фильтрации для выбранного атрибута:

В итоге должен получиться такой вид:

Далее - несколько раз нажимаем Ок. обновляем в Конфигураторе БД (можно клавишей F5) и перезапускаем КК. После этих манипуляций в карточке Склад.Поступление список контрагентов будет отфильтрован по признаку поставщик. 

Ещё желательно добавить в разрешенное условие и собственные предприятия, что бы списания в производство (на себя) корректно отображалось.

Как будут новости - с выходом очередного релиза КлиК, сразу же сообщим.

Ромб был приведен в качестве некоторой утрированной крайности, хотя я лично видел, как в реальности на IDEALe лист ровно режется на полосы и потом каждая полоса под углом делиться на "параллелепипеды".

Но сейчас не об этом речь. 

Возвращаясь к вопросу о том, что "заводить надо шаблоны под каждое изделие" - скорее под каждый тип изделия, например под визитку, листовку, календарь. Понятно, что при нестандартном размере изделия и/или печатного листа кол-во резов (или других операций) надо будет считать как бы заново, но то в любом случае простым алгоритмом не универсализируешь. Я видел как те же самые визитки кто-то режет лист в 9 резов, а  кто-то сперва его половинит и отдельно нарезает каждую половину ибо ему так удобнее... и даже видел, как с отдельной полоской (по длинной стороне) работают - тогда резов получается уже 24... как это может быть учтено в универсальном алгоритме непечатной операции? 

Ещё один аргумент в пользу сохранения текущего алгоритма в программе - непечатная операция сейчас является единой и комбинацией затрат материала и кол-ва операций на единицу/кол-во/тираж изделий можно описывать различные виды постпечатки, даже банальную упаковку в коробку или пересбор клиентской коробки после накатывания на ней чего-нить (сам лицезрел, как трое бодреньких тётушек разбирали коробочки с USB-модемами от сотового оператора и после замены части отбрендированных элементов оформления заново всё склеивали). Наша подход позволяет это описать, пусть и не двумя кликами, но тем не менее. А если вводить алгоритмический расчет на каждый вид постпресса, то потребуется реализовывать алгоритмы для всех их и постоянно наращивать кнопки-функции.

Хотя допускаю, что при наличии большого числа запросов со стороны пользователей, мы к этому вполне можем прийти. 

Конкретно Ваш пример со стопкой в 40 листов решается следующим образом:

- на одном листе 24 изделия

- один лист режется, допустим, 21 рез

- за один раз резак может пропустить до 40 листов

- 40 листов = 960 визиток

ИТОГО: 21 рез на 960 визиток

Именно такая формула задаётся в карточке непечатной операции. В таком случае система будет считать по логике - меньше 960 визиток = 21 рез. Между 960 и 1920 = 42 реза. И т.д. с шагом в 960 визиток...

Скорее всего таким способом можно описать подавляющее большинство вариантов. Хотя готовы признать, что некоторые граничные нюансы остаются.