Здраствуйте.
Подскажите пожалуйста, может кто сталкивался с такой ситуацией:
1С:Предприятие 8.2 (8.2.14.540)
"Бухгалтерия для Украины", редакция 1.2.
Разработка конфигурации: "ABBYY Ukraine", 2005-2011 (1.2.6.5)

N.B. Конфигурация не изменялась

Замечена некая нестыковка между табличной части документа и формой сохранения в xml или печатной формой.
Есть НН в табличной части которой содержится 541 позиций товара, при нажатии кнопки Выгрузить в XML открывается стандартная форма сохранения в XML, в которой 536 позиций.
В печатной форме тоже 536 позиций.
Непонятно куда пропали 5 позиций.

Также подобная закономерность обнаружена и в других НН, например в ТЧ 172 позиции, а в форме XML или печатной форме - 171. Тут пропала 1 позиция.

Подскажите пожалуйста, что это может быть - так ли это должно быть и если нет, то куда капать.
Спасибо.
С Уважением, Дмитрий.

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

Распечатал Налоговую и построчно сверял ее с табличной частью.
Выяснилось, что Печатная форма или ФормаВыгрузкиXML объединяют позиции (ИМХО) исходя из содержимого осноного поля Номенклатура и остальных полей (КодУКТВЭД, Цена, возможно других) и если они одинаковы, то объединяет.

Но видимо это происходит неверно, т.к. поле Номенклатура является Ссылкой на справочник Номенклатура., а в моем случае это совершенно разные товары.
Я сделал следующее ДБЛклик по яцейке Номекратура (Табличной части), потом кнопку, в открывшемся справочнике номеклатура на текущем элементе, правой кнопкой мыши выбрал изменить и посмотрел данные элемента. Так же проделал и для второго элемента .

В табличной части НН выглядит так
Номенклатура КодУКТВЭД Кол. Цена
Кронштейн пер. пр. 830....090 2 15,83
Кронштейн пер. пр. 830....090 1 15,83

А на самом деле если развернуто посмотреть, то так
Код Артикул Наименование
0...02354 86514-2F500 Кронштейн пер. пр.
0...02311 86518-2F500 Кронштейн пер. пр.

Как видно, то товары совершенно разные как по Артикулу, так и по первичному ключу.
Получается, что при печати или экспорте в XML программа не обращает внимание на Код и Артикул.

Как можно это исправить, может есть настройки, которые позволят отключить это неверное объединение, а то получается несоответствие как печатной формы, так и XML файла с Налоговой накладной?

Спасибо.
С Уважением, Дмитрий.

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

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

Спасибо Вам большое.
С Уважением, Дмитрий.

А чем физически отличается эта номенклатура?

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

Это не физически, это логически.


Как разные запчасти могут одинаково называться?


Если цена будет разная, то в НН будут разные строки.

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

Хотя все вышесказаное ИМХО, возможно в конфигурации есть механизмы для рабора такого (таких?) случая.

Тогда я не понял вопрос касательно физического отличия товара - поясните пожалуйста.

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

Если я правильно понимаю, что в конфигурации идентификация задумывалась по наименованию товара, например "Арбуз "Симеринка"" и соответственно артикул можно и не использовать.

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

Надо было использовать серии.


Т.е. у вас в базе, условно говоря, по 100 номенклатур с одинаковым наименованием?

Сам понимаю, что , и ничего поделать пока не могу, т.к. корни идут от ТиС 7.70.005 ниразу не обновлявшаяся и многократно переделанная/допиленная, а 1С 8.2. у нас только бухгалтерия (надеюсь, что в будующем перейдем на 8 УТ), может тогда получиться что-то изменить.
А пока у нас в Справочник.Номенклатура так

Код             КодТ       Наименование       НаимАнгл      ...
0001      28113-2F000     Фильтр воздушный      Filter Air       ...
0002      28113-3K000     Фильтр воздушный      Filter Air       ...
0003      28113-22001     Фильтр воздушный      Filter Air       ...
0004      28113-2D000     Фильтр воздушный      Filter Air       ...

где Наименование и НаимАнгл в свою очередь являються (не знаю как правильно называються - типа указатель на объект или ссылка) Справочник.Наименование и Справочник.АнглНаименование.

Я например пока не вижу как можно в нашем случае сделать с разным наименование, разве что в каждом наименовании дописать номер детали.

Соответственно если Код является уникальным автоинкрементом, то КодТ нет - юзеры периодически создают дубликаты, пыталься сделать "искусственное" ограничение уникальности этого поля (т.к. в 7.7 в отличии от 8.2 для артикула такого нет), пока не получилось, пытался сделать проверку - получилось, но не совсем достойно имеються большие "дыры".


А скажите пожалуйста в 7.7 серии присутствуют или они появились в 8-ке?

И наверное привести все это хозяйства в надлежащий вид потребует немало усилий и времени и есть ли смысл до перехода на 8?

С Уважением, Дмитрий.

Я не помню уже, может кто-то другой подскажет.


Я так понял, что вы уже в 8 учет ведете. Не?

Основная база с которой все работают это 7.7 ТиС, а в 1С8 Бухгалтерия работает только бухгалтер и то данные посредством ОЛЕ переносятся из 7.7 ТиС в 8.2 Бухгалтерия после чего бухгалтер сохраняет налоговые в XML и импортирует их в m.e.doc, а потом отправляет в налоговую.
Но основная деятельность (продажа) все же в 7.7 ТиС.