Andreeei
Андрей Микаилов

(13)

> А все типовые процедуры, которые вы вынуждены были изменить - будут работать так, как это задумал их создатель

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

Наверное ваша технология хороша, но ее надо дополнить условиями применения (если, конечно, это возможно, но скорее всего, каждый раз надо очень прилично задумываться, перед тем, как начинать ей следовать))

(11)
> Для того,чтобы этот алгоритм реализовать, вы внесли изменения в типовую?

Да, реквизиты добавили в типовую, процедуры изменили расширением.

> Какие объекты изменили?

- Справочник "Варианты комплектации номенклатуры";
- Обработку "Редактирование наборов";
- Табличные части документов, где используются наборы;
- Обработки заполнения для копирования наборов между документами;
- Процедуры формирования печатных форм.

Самая большая неприятность в том, что печатная форма УПД (документа реализации) строится на основании табличных частей "Виды запасов" и "Товары", причем виды запасов и товары могут быть в самых разных соотношениях, одному товару может соответствовать несколько видов запасов, и наоборот нескольким одинаковым товарам может соответствовать одна строка с видом запасов. Распределять строки одной таблицы по строкам другой таблицы при формировании УПД бывает долго (зависит от размеров таблиц товаров и видов запасов), поэтому пришлось присобачить в документ реализации еще одну свою расширенную таблицу видов запасов, с реквизитами про набор (идентификатор набора, наименование набора, количество наборов), заполнять эту таблицу вместе с заполнением типовой таблицы "Виды запасов", и использовать ее вместо типовой.

Примерно так.

(8) Допустим, в физическом мире есть наборы "Мебельный гарнитур черный" состоит из комплектующих "Стол черный" (1 шт) и "Стул черный" (1 шт), 2); "Мебельный гарнитур белый" состоит из комплектующих "Стол белый" (1 шт) и "Стул белый" (1 шт); и прочие цветные наборы всех цветов радуги.

В ЕРП наборы используются для удобного подбора в документы (например, в заказы клиентов), и для группировки товаров в печатных формах примерно так:

- "Мебельный гарнитур черный" ( 1 шт) :
-- "Стол черный" (1 шт)
-- "Стул черный" (1 шт)

- "Мебельный гарнитур белый" ( 1 шт) :
-- "Стол белый" (1 шт)
-- "Стул белый" (1 шт)

В типовом функционале, чтобы это использовать, требуется завести все варианты набора (по количеству цветов в данном случае).

Беда в том, что количество наборов (в реальной жизни) быстро становится слишком большим, и работать с ними становится не удобно.

Поэтому родилась идея - держать только некий основной набор, пусть, например, черный (или бесцветный, неважно). Если надо продать, например, белый набор, то при подборе комплектующих в заказ выбираем основной набор, меняем характеристики комплектующих на белый цвет, и переименовываем набор в документе так, как надо.

Получается примерно тоже самое, что в типовом функционале, но количество наборов намного меньше.

(Да, в наборе еще может быть другое количество стульев, да и столов тоже, и может быть добавлена табуретка))

(И наборы должны сохранятся при создании при создании заказ на основании коммерческого предложения, при создании реализации на основании заказа...)

(6) Это и есть конкретный пример из реальной жизни)

(4) > почему возникает такая потребность, зачем надо менять основную комплектующую или характеристику

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

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

> Там, где типовые механизмы не имеют нужной функциональности...- создаем свои объекты - справочники, документы, регистры, ...

Допустим, в ЕРП заказчику необходимо произвольно редактировать наборы в документах, в том числе, менять / удалять основную комплектующую и/ или ее характеристику, при этом модифицировать наименования наборов и задавать количество. Т.е. в документе может быть несколько наборов, полученных из исходного, которые могут отличаться составами, наименованиями, количествами. В печатных формах наборы должны быть выведены каждый со своим наименованием, комплектующими, и в заданном пользователем количестве.

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

Или ваша технология не применима к мелким задачам?

Можно ли где-то посмотреть пример ее применения?

В УНФ и БП разные принципы контроля остатков:

- В УНФ в момент проведения расхода учитываются все поступления, даже те, которые имеют дату после даты расхода.

- В БП это не так, документы с поздними датами не учитываются.

После обмена может оказаться, в УНФ расход провелся, а в БП нет.

Как правильно выкручиваться из таких ситуаций?

&ИзменениеИКонтроль не помогает замечать и предупреждать ошибки обновления, если поставщик конфигурации меняет имя исходной процедуры. У меня такое было, например, при последнем обновлении ЕРП: в модуле МенеджерОбменаЧерезУниверсальныйФормат изменилось название процедуры, было "ПОД_Документ_ВнутреннееПотреблениеТоваров_Отправка_ПриОбраб­отке" стало "ПОД_Документ_ВнутреннееПотребление_Отправка_ПриОбработке". Проверка применимости расширения этого не заметила. В результате в продуктиве появилась ошибка, которую очень даже заметили пользователи.

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

Небольшая доработка, позволяющая при расчете плановой калькуляции получить более полное дерево, включающее в себя материалы полуфабрикатов, производимых на стороне. Была выполнена для ЕРП 2.5.12.

Как вы сравниваете остатки (на основе какого отчета или регистра wms) с учетом того, что в wms движения отстают по времени от движений по складу в ЕРП на случайную величину (зависящую от оперативности приемки - отгрузки)? Например, если сравнивать отчеты об остатках в ЕРП и в wms на один и тот же момент времени, то они принципиально не совпадают.