разбиение при переносе на партии

[Волчара]

Проблема простая:
Требуется перенести определенное количество номенклатуры со склада 1 на склад 2
Мы создаем журнал переноса с авторезервированием
Создаем строчку - перенести номенклатуру со склада 1 на склад 2
Система резервирует номенклатуру на складе 1 в трех разных партиях
В результате по строке у нас получилось 4 складских проводки
склад 1 партия а зарезервировано
склад 1 партия б зарезервировано
склад 1 партия в зарезервировано
склад 2 заказано

Внимание вопрос:
Есть ли в аксапте функциональность которая позволяет автоматически разбить проводку прихода на склад 2 на три проводки с разными партиями с соответствующими количествами?

[Елена Сысовская]

с нумерацией партий в 3.0 что-то не то...
вообще, есть автоматическая нумерация партий, она может включать номерную серию или параметры строки - дата, номер лота и пр.
этот функционал должне сработать и в 2.5 работал. Можно было не указать партию "жестко" - она ее создавала сама. В 3.0 что-то у меня не получилось. Может, сама чего напортила.

[Волчара]

Может быть я неясно выразился - постараюсь учтонить
Генерить новый номер партии не нужно
Товар лежит на складе 1 в какихто партиях - нужно перенести его на склад 2 сохранив при товаре признак партии

Судя по вялой реакции (к вам Елена это не относится) такой функциональности нет.
Значит, для правильного сохранения аналитики партии надо в ручную создавать несколько строк в журнале с разными партиями.

Вообще проблема относиться не только к партии но и ко всей другой аналитике, кроме аналитики местоположения. А этой другой аналитики в трешке пруд пруди.

Пришлось написать прогу.

[Artem2003]

Нельзя.

Маленький совет: было бы хорошо сообщить для какого случая эта функциональность используется.

Информация для размышления:

1) Обязательное сопоставление складских проводок на приход и расход (по коду "Партии") необходимо для того, чтобы не потерять "финансовый склад" в разрезе партий (в случае, если он указан в модели складских аналитик), иными словами производит учет себестоимости номенклатуры в разрезе партий.

2) При такой функциональности (согласно вопросу) теряется смысл Бизнес - процесса приемки партии номенклатуры на склад, то есть в этоге межсладской перенос был совершен как бы "по умолчанию". Есть случаи, когда партии регистрируются. А вдруг мы 1 шт. потеряли. Мы так на прибыли и убытки даже ничего списать не сможем, даже, если захочется. Перенос в системе будет как бы скрыт от пользователя.

3) Часто резервирования партии производится, если партий много для переноса на другой склад. Понятно, что вручную партии выбирать "в лом".

4) Понятно, что и партии регистрировать будет "в лом", соответственно возникла такая необходимость, но каким образом мы теперь будем находить отвественного за этот бардак (???). Как будем сопоставлять физ. расход по складу А (потери 1 шт.) с определенным приходом при переносе на склад А.

Итог:
1) Принимая во внимание п 1-4 слово "нельзя" логически оправдано в системе.

2) Прога была написана на уровне складских проводок (клиент ничего не видет или не понимает) - какая нибудь галочка на уровне складского журнала переноса.
Либо на уровне формы "Регистрация" путем автоматического разбиения и автоматического проставления галочек "к регистрации" сейчас (маловероятно, функциональность посложнее).
-> Совет будь осторожен, принимая во внимание пункт 2.
Угрозы:
1) Попросят дописать функциональность по учету потерь может оказаться намного больше первой проги)и прочее приколы которые выявятся потом .
2)Может влететь за нарушение бизнес - логики в системе.

Удачи.

[Волчара]

Цитата:

Изначально опубликовано Artem2003
Нельзя.

Маленький совет: было бы хорошо сообщить для какого случая эта функциональность используется.

Это будет работать так:
а) При создании строки журнала переноса сформировались проводки и номенклатура зарезерировалась в разных партиях.
б) Распечатка расходных проводок по журналу есть задание для сборщика на складе. На всех коробках указана партия.

Цитата:

Изначально опубликовано Artem2003
1) Обязательное сопоставление складских проводок на приход и расход (по коду "Партии") необходимо для того, чтобы не потерять "финансовый склад" в разрезе партий (в случае, если он указан в модели складских аналитик), иными словами производит учет себестоимости номенклатуры в разрезе партий.

Правильно, но не только. Есть еще другие интересные проблемы. Например:
В коробке обнаружился брак. Надо проверить всю партию. А где ее искать?

Цитата:

Изначально опубликовано Artem2003
2) .... Перенос в системе будет как бы скрыт от пользователя.
3) Часто резервирования партии производится, если партий много для переноса на другой склад. Понятно, что вручную партии выбирать "в лом".

2) не будет скрыт. Есть отчет задание на сборку - печатается из проводок.
3) оптимизация работы оператора склада может быть одной из целей внедрения


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

[Logger]

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

Для начала описываю проблему.

Журнал перенос при включенном авторезервировании корректно резервировал расходные проводки (сплитил их, проставляля необходимые аналитики), но не сплитил и не ставил аналитики для приходных, выдавая что "Код аналитики %1 отмечен в складских проводках со значением %2"

InventDim ToInventDim
Склад ЗН1 ЗН2
Наша 1 пусто ЗН4
Наша 2 ЗН3 пусто

Заполнены были только аналитика склад и пара наших собственных.
Остальные пустые.
------------------------------

Как лечили :

Таблица InventDim
метод

void mergeUsedDim(InventDimGroupId _dimGroupId,
InventDim _fromInventDim,
InventDim _origFromDim = _fromInventDim
, boolean forceMergeAll = false
)
{
InventDimSearch _dimSearch = new InventDimSearch();
Integer x;

if (_dimSearch.first(_dimGroupId))
do
{
x = _dimSearch.dimFieldId();

if (_dimSearch.dimActive())
{
if (_fromInventDim.(x)
|| forceMergeAll // принудительно даже пустые копируем
)
this.(x) = _fromInventDim.(x);
else
if (this.(x) && this.(x) == _origFromDim.(x)) // clearing a dimension on the movement, but no on transaction
info(strfmt("@SYS73455", new DictField(tableNum(InventDim),x).label(), this.(x)));
}
} while (_dimSearch.next(_dimGroupId));

// HF21_394
if (this.WMSLocationId && !this.WMSLocation())
{
this.WMSLocationId = '';
this.wMSPalletId = '';
}
}

В общем добавили параметр, который принудительно копирует все активные аналитики, а не только активные непустые.


Далее
Класс InventUpdate
метод
updateTransDimTransferReceipt()

вызов
inventDimReceiptOrig.mergeUsedDim(movement.dimGroupId),movementReceipt.inventdim());
заменили на
inventDimReceiptOrig.mergeUsedDim(movement.dimGroupId(),movementReceipt.inventdim(), movementReceipt.inventdim(), true);


Идея изменений :
метод берет расходную проводку и её аналитики до изменения. Перепрописывает в неё НЕПУСТЫЕ активные для данной группы номенклатуры аналитики из ToInventDim из строки переноса. И пытается с фильтром по полученной аналитике найти приходные проводки чтобы проставить в них аналитики (ну если потребуется, рассплитить).

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

Кто нибудь менял этот механизм ?
Беспокоит вот что - возможно разрабтчики Аксапты неслучайно копировали только непустые значения. А метод InventUpdate.updateTransDimTransferReceipt() вызывается в куче мест.

Вот думаю, может сломали где чего, и пока не заметили.

[Atar]

Цитата:

Сообщение от Волчара

Проблема простая:
Требуется перенести определенное количество номенклатуры со склада 1 на склад 2
Мы создаем журнал переноса с авторезервированием
Создаем строчку - перенести номенклатуру со склада 1 на склад 2
Система резервирует номенклатуру на складе 1 в трех разных партиях
В результате по строке у нас получилось 4 складских проводки
склад 1 партия а зарезервировано
склад 1 партия б зарезервировано
склад 1 партия в зарезервировано
склад 2 заказано

Внимание вопрос:
Есть ли в аксапте функциональность которая позволяет автоматически разбить проводку прихода на склад 2 на три проводки с разными партиями с соответствующими количествами?

Что то не то в канцелярии.
У меня (3.0 SP4) в таком случае нормально создаются 3 приходных проводки на ТЕ ЖЕ партии.
Это стандартная функциональность.

[Atar]

Цитата:

Сообщение от Atar

Что то не то в канцелярии.
У меня (3.0 SP4) в таком случае нормально создаются 3 приходных проводки на ТЕ ЖЕ партии.
Это стандартная функциональность.

Там есть, правда ограничения, без соблюдения которых возможна описываемая Вами ситуация:
- для указанных в строке аналитик всегда должна быть указана парная аналитика
(т.е. обе: "Из" и "На" должны быть заполнены)
- набор аналитик "Из" должен отличаться от набора аналитик "На"

[Logger]

А если при этом в строке в аналитике Откуда для переноса склад потереть, а для Куда оставить с каким то значением то тоже все нормально будет ?

[Logger]

Цитата:

Сообщение от Atar

Там есть, правда ограничения, без соблюдения которых возможна описываемая Вами ситуация:
- для указанных в строке аналитик всегда должна быть указана парная аналитика
(т.е. обе: "Из" и "На" должны быть заполнены)
- набор аналитик "Из" должен отличаться от набора аналитик "На"

Вот вот, и я про то же.

Интересно, требование чтобы обе аналитики были заполнены ("Из" и "На") это багофича, или это специльно так сделали, и отключать это нельзя?

А то я вот отключил, и думаю, может зря ?

[Atar]

Цитата:

Сообщение от Logger

А если при этом в строке в аналитике Откуда для переноса склад потереть, а для Куда оставить с каким то значением то тоже все нормально будет ?

В каких то ситуациях аналитика в проводках сохраняется.
Даже какое то сообщение по этому поводу появляется.

[Atar]

Цитата:

Сообщение от Logger

Вот вот, и я про то же.

Интересно, требование чтобы обе аналитики были заполнены ("Из" и "На") это багофича, или это специльно так сделали, и отключать это нельзя?

А то я вот отключил, и думаю, может зря ?

Просто тогда надо придумывать алгоритм как в проводки эту аналитику подбирать. Это дополнительные модификации.

[Logger]

Я ошибся.

Хотел другой случай указать, когда в строке аналитика расходная есть а приходной нет.

[Atar]

Мне кажется в нормальных ситуациях в жизни не должно возникнуть потребности оставлять одну из аналитик пустой.
Что это должно быть? Собрать товар определенной партии со всех складов на определенный склад?
Лучше с этим не связываться, а заставить в несколько строк такие перемещения заводить.

[Atar]

Цитата:

Сообщение от Logger

Я ошибся.

Хотел другой случай указать, когда в строке аналитика расходная есть а приходной нет.

Тогда лучше сделать гораздо более простую модификацию - при сохранении (создании и обновлении) строки копировать аналитику "Из XXX" в аналитику "На XXX", если "На ХХХ" не заполнена.

Это конечно, если вы уже дошли до такой стадии, когда подобные фишки вам нужны

[Logger]

Цитата:

Сообщение от Atar

Тогда лучше сделать гораздо более простую модификацию - при сохранении (создании и обновлении) строки копировать аналитику "Из XXX" в аналитику "На XXX", если "На ХХХ" не заполнена.

Это конечно, если вы уже дошли до такой стадии, когда подобные фишки вам нужны

К сожалению нельзя.
Аналитика "На XXX" в нашем случае должна быть строго пустой в строке переноса и в соответствующих приходных проводках тоже.

[Atar]

Цитата:

Сообщение от Logger

К сожалению нельзя.
Аналитика "На XXX" в нашем случае должна быть строго пустой в строке переноса и в соответствующих приходных проводках тоже.

Сегодня пятничное настроение, думать не хочется

Если не секрет, откуда потребность делать такие переносы?

Цитата:

InventDim ToInventDim
Склад ЗН1 ЗН2
Наша 1 пусто ЗН4
Наша 2 ЗН3 пусто

[Logger]

Цитата:

Сообщение от Atar

Сегодня пятничное настроение, думать не хочется

Если не секрет, откуда потребность делать такие переносы?

Делов том что это наша аналитика. Пустое значение тоже имеет смысл. Можно считать его значением по дефолту.

Эти журналы вообще программно создаются.

[Atar]

сделали бы вы тогда лучше какой-нибудь значок вместо ноля.
Иначе Axapta всегда будет считать, что значение просто не введено.