Например в 1С:Предприятие 8.3 (8.3.10.2561) Бухгалтерия для Украины, редакция 1.2. (1.2.44.2) я никакого ограничения в дублях строк в ТЧ я не увидел.
Там получается Партионное списание не используется?

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

Соответственно, в чем может быть проблема в партионном списании, если товар "упал" в одну партию по средней цене?


Я это предполагал, но какие еще поля ТЧ кроме Номенклатуры могут еще проверятся на дубли?

Могу предположить, что "Ед.Изм" и "Коэффициент" м "Характеристика номенклатуры".
Но каким образом "Ед.Изм" учавствует, если она почти у всех товаров одинаковая "шт.", "Коэффициент" всегда = 1 (по крайней мере у нас), да и не понятно для чего он вообще нужен.
С "Характеристикой номенклатуры" также не все однозначно, для меня не совсем понятно для чего эта характеристика нужна.

Я попробовал продавать товар с нескольких строк, выбирая разные варианты списания партий для каждой из строк.
Я не заметил каких-то сбоев, товар списывался согласно выбранной партии.

Единственно был отмечен такой глюк:
Если в ТЧ есть дубли строк товара и открыть форму ФормаПодбора, в ней выбрать такой же товар, указав некоторое количество и нажать ОтправитьВДокумент, то количество для одноименного товара в ТЧ увеличится на некоторую величину, но фишка в том, что оно увеличится сразу для всех строк дублей. Но этот глюк не приносит слишком больших неудобств и думаю, что его можно как-то обработать.

Каких-то других более серьезных глюков пока не выявлено.

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


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


это касается абсолютно всех документов, может же быть ТЧ сотрудников, где тоже нужен контроль уникальности, исходя из этого я бы не стал отключать контроль в глобальной процедуре, а искал бы параметры при вызове этой процедуры в локальном месте

ПС.Ещё раз повторюсь, мой опыт может быть не актуальным на сегодняшний день, мой совет - лишь перестраховаться, если проблемы вылезут после какого-то времени использования, исправлять будет намного сложнее

Сообщение отредактировал Макс1С - 18.12.19, 2:13

Во-первых, это другая конфигурация.
Во-вторых, на сколько я помню, в Бухгалтерия для Украины таблицы при списании партий сворачиваются.

Я пробовал три строки одинакового товара, при этом на складах было 3 партии товара.
По первой партии товар был на двух складах, остальные партии были на одном.
Например так
Партия Склад1 Склад2 Себест
№1 2 1 2,00
№2 3 0 10,00
№3 2 0 15,00

В реализации со склада1
Строка № Кол-Во Цена продажи
1 3 4,00
2 2 4,00
3 1 4,00

Цена подставляется 4.00, т.к. последнее Изменение цен была расчитана на 4,00

В итоге:
- по первой строке оно продало 2 шт из Партии №1 по 4.00 и 1 шт из Партии №2 по 4,00, но выдало сообщение что продажа ниже себестоимости, т.к. партия №2 по 10,00. (разница 6,00)
- по второй строке продано 2 шт из Партии №2 по 4.00, также с сообщение ниже себестоимости. (разница 6,00)
- по третьей строке продано 1 шт. из Партии №3 по 4, ниже себестоимости (разница 11,00)

Т.е. как бы так как и задумывалось.


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

А дублирование строк в ТЧ я отключил закомментировав одну строку кода в ОбщемМодуле дкДокументы в функции дкПроверкаКорректности(...), что влияет только на дублирование реквизита Номенклатура в ТЧ и соответственно никак не влияет на документы в ТЧ-х которых не содержится реквизит Номенклатура, и тем более на справочники.


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


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



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

Еще один момент, который мне бросился в глаза, это то, что в бухгалтерии документы с большим количеством строк в ТЧ обрабатываются как-то быстрее (загрузка из файла табличного документа, проведение документов), чем это происходит в Альфе, из-за чего пользователи в Альфе жалуются, что как-то долго приходится ждать , чтобы загрузить данные из файла в ТЧ, а также при проведении (например кол-во строк около 10000 строк).
С чем это может быть связано и возможно-ли в Альфе это оптимизировать и ускорить?

В альфе структура регистров сложнее. К тому же, альфа в плане продуктивности работы с бд слишком устарела. В росийской 5-й версии уже перевели на управляемые блокировки. В 4-й такого нет и не будет, пришлось дорабатывать - намного легче стало жить пользователям. Но если еще и оптимизировать структуру регистров, да перевести на управляемый интерфейс - будет еще лучше. Но это будет уже другая конфигурация...