Старенькая ТиС. Возникла необходимость расфасовывать и продавать весовой товар. Например - зашел Сахар 100 кг. ---> расфасовали по пакетам 30х1кг+ 10х5кг+ 10х2кг. и продаем поштучно. Все бы ничего,но из этого ТиС идет выгрузка в бухию и бухгалтера однозначно хотят видеть все движение в килограммах (никаких превращений в штуки!). Поэтому в бУхию планирую суммировать и  выгружать килограммы. Соответственно надо и остатки сверять в обеих базах. Как лучше подойти к решению? Сделать еще один регистр Остатки2, куда записывать трансформированные штуки в килограммы и потом к нему обращаться уже?

(0) Смотрите единицы (кг - упак). Там геморройно (в стандарте), но приспособить можно.

(1) непонял идею. как приспособить?

пониаешь тут в чем беда будет - тебе придется и торг12 и счф формлять в килограммах. и цену - за килограмм.

(1) не получиться... ТС стопудово надо будет знать сколько каких пакетов. если этого знать НЕ НАДО - тогда проблем никаких - в том случае если клиент заказывает нужный вес.
Сахар, базовая единица = кг, производные единицы - пакеты.
все доки оформляются в кг.
на отгрузку отдается "сборочный лист" с примечанием как собирать - от крупных к мелким пакетам или наоборот.

но вся проблема что клиент скорее всего закажет именно отгрузку килограммовыми пакетами

(4) Да, именно пакетами, которые уже штуки

второй вариант
Группа "Сахар"
в ней элементы "Сахар 1кг", "Сахар 2кг"...

в ТИСе производишь перефасовку. списываешь 100 кг.
оприходуешь три разных номенклатуры, количественный учет = штучный

при выгрузке (смотря как она сделана) - можно выгружать "родителя" с пересчетом в Кг

(5) что "именно пакетами"?
клиент заказывает отгрузку именно конкретными штуками..?

(7) да, 3 пакета по 1кг., 2по 2кг. и т.д.

может кто из "колдунов" что-нить еще веселое придумает?
вариант в (6) мне кажется проще чем городить допрегистр.

(6) Т.е. сделать подчиненный справочник-клон "Товары"?

Это получаются разные товары?
Завести справочник "КлассификаторУникальныхТоваров" - ввести туда товар, "Сахар-песок", засунуть в номенклатуру, добавить реквизит коэф пересчета и в выгрузках умножать.

но! можно извернуться ЕЩЕ ХИТРЕЕ
.
в регистр.остаткиТМЦ в измерение "Цена" (которое предназначено для розницы) - писать число, эквивалентное весу пакета и ли количеству пакетов. и подшааманить списоание остаткокв

(10) Не "Владелец". А "Родитель" - группу товаров

(13) Ну, как я группу выгружу в элемент? Я еще думал сделать еще одну табличную часть и в ней Элемент Товары2, который будет связан с Товары из основной таблицы через коэфициент

(11) Можно в КУТ впихнуть реквизит "Основной товар" и перегружать его в килограммах.
Короче варианты разные.

У нас справочник "КлассификаторУникальныхТоваров" вырос из того, что много товара с разными цветами, на все их характеристики и цены задолбешся запоминать. По этому ввели такую прослойку. И привязали к КУТам файлы, характеристики, совместимости и прочее.

то есть 100 кг будет в регистре остатков так:
цена=1 колво=30кг
цена=2 колво=20кг
цена=5 колво=50кг
и в зависимости от флажка "весовой" малость подшаманить процедуру списания остатков по продаже. А перефасовка вообще тривиально делается

(14) да мну пофиг как ты выгрузишь. я могу выгрузить так как нужно. а не так как навязано хрен знает кем. если выгружаешь с богомерзкой КД - там вместо элемента подсунуть в выгрузку в качестве элементиа группу - навоз вопрос

(16) ну перефасовку планирую сделать из "СписаниеТМЦ"+"ОприходованиеИзлишков" соединиы как бы два этих дока в один

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

(17) Не, ОЛЕ выгрузка

(18) ну да, типа списывает 100 кг,ц=0, приходуешь по ц=разная

(20) ну так какая проблема? взял элемент, по какому-то признаку - взял родителя. и ищешь его в бухбазе как элемент

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

не, вариант 16 не сильно прозрачный. надо сильнее думать. ща Масяня придет и женской изворотливым умом даст рецепт

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

(23) вот вот. Я тоже уже перегрелся. Только Масяня решает?

А много движений? База большая?
А то пару ресурсов в пару регистров добавил и усе.

ТиС какая? Если цена в регистре есть, значит 9.2 какая-нить.

(25) в этом тисе нет комплектов(. И комплект это же четкое представление- например Комплект чашек= Чашка синяя 1шт + Чашка красная 1шт. А если синяя 1 шт. а красная 2шт- уже другой комплект

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

старая 027 и для Украины

+(27) Это к вопросу о сверке. Там же и решение о выгрузке.

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

(30) Сверку поштучно тоже делать надо. Низя суммировать штуки и кг.

(8)"да, 3 пакета по 1кг., 2по 2кг. и т.д."

ну и прекрасно, будет 1 строка ЕИ "Пакет сахар 1 кг"  Товар "Сахар" Кол-во 3 шт, 2 строка ЕИ "Пакет сахар 2 кг" Товар "Сахар" Кол-во 2 шт, и т.д. В движениях получишь движения сахара в кг. Базовую единицу задаешь килограмм, для остальных единиц перевод по коэффициенту в 1 кг.

(33) вот я тоже к этому склоняюсь. Только скопировать регистр и подшаманить его, и строить отчеты по тому и по тому, в зависимости в чем надо в кг. или шт.

(34)сверку с кем?

(36)зачем плодить сущности? чем штатный перевод по коэффициенту не устраивает?

тогда проще:
базовая ед = КГ
производные ед = пакеты
добавить в регистр.остатки измерение "ЕдиницаХранения"
тупо поиском взять по конфиге и обработкам посик на этот регистр и модифицировать получение остатков и запись регистра.

в отчетах по оатсткам = остатко = Колво/ед.
если ед=пусто, то остатко = колво

(38) требуется знать скольо на остатках конкретных фасовок

(36) Я вот не советую зоопарк из регистров разводить.
По этому и спрашиваю БД большая?

(35) надо тоже покурить но не сегодня, может и получиться. Я не все могу сформулировать просто. тут еще есть навороты

(41) не, бд 2 года всего

(41) присоединяюсь

(40)тогда понятно, спасибо за пояснение

+(41) Просто сахар - не единственный весовой товар :)
Печеньки, прянички, конфетки и т.п.

или в регистр остатков при записи писать колво = количество именно в заданной ЕД.

(43)за 2 года много можно наколотить

надо поставить WMS, в ней работать так как вреале работает склад, а в торговую базу обменами меняться ;-) .. в килограммах...

(48) нет не очень, порядка 2000 доков в год

(49) При небольшой БД это не особо и нужно.
ПС. Я просто не врубаюсь в чем прелесть WMS :)

Итого - я сделал как в (6) бы... МИНИМУМ ПЕРЕДЕЛОК

(52) Сверка?
я про:
(0) > Соответственно надо и остатки сверять в обеих базах.

естественно просто надо выяснить что действительно необходимо.
Некоторые вещи можно и на калкулторе посчитать.

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

.. правда это было пока и торг и бух были на 7.7. ща бухия на 8-ке и прямого коннекта нет. в файлик выгружается, в бухии загружается - итог тот же самый протокол

(56) Аналогично. Тис выгружается в бухию 8, только по оле в конце дня. И сверка регистров остатки реализована в виде сравнительного отчета (протокол это или нет не знаю)

(57) Коды товаров соответственно одинаковы

(58) ну и делай как в (6), а в выгрузках и сверках оперируй Группой-"Родителем" - она должна у тебя имет такой код, как код у элемента "сахар" в бухбазе

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

(60) если кода идентичны - не сношайте себе мозг. веди учет в бухбазе. нафига вам две базы ...

старенькая это 2,0 проф фор дос )

без серьезной переписки проведения будет трудно это реализовать
я делал так
1. делаешь реквизит базовыйтовар и коэфф списания (Это куча сахара в кг )
2. Делаешь столько карточек товара сколько нужно
типа Сахар 5кг, Сахар 10кг в это карточках прописываешь "БазовыйТовар" и КоэфСписания (5,10 И Т.Д.)
3. переписываешь проведения документов там на самом деле не сложно
4. Продаешь  клиентам только с Карточек Сахар 5кг, сахар 10кг

все задача решина

А если перейти на УТ11? Там это реализовано?

Меняйте номенклатуру и все будет замечательно.

Был "Сахар в килограммах" стал после расфасовки "Сахар в пакетах по X кг", для каждой новой уникально-пакетной номенклатуры храним исходный вес в реквизите справочника и исходную номенклатуру.

В результате при выгрузке в Бух банально проверяем есть ли (заполнен) реквизит исходная номенклатура и если есть то делаем подмену на нее в кг.

(65) тьфу опоздал (( уже (63) тоже самое, не читал всю ветку

Миллион вариантов.
-Просто в единице завести реквизит "ВесНетто".

-А проще конечно базовую единицу на все товары "Кг"
-при фасовке заводить новую номенклатуру (в УТ)
базовая такая-же (Кг), основная - согласно затарке.

Дописок не требуется вообще, ибо документ "КомплектацияТМЦ" в типовой есть. Ну разве что обмен с бухгалтерией немного переписать в зависимости от хотелок. Например с подменой товара на "объединенную карточку". Выгружать документами, себестоимость сама посчитает при проведении.

Остатки сверяются элементарно (практически все отчеты в Тис можно формировать как в базовой так и в основной единице)

(67) опечатка
-при фасовке заводить новую номенклатуру (в ТИС)

Если нужны отчеты с консолидацией номенклатуры в одну карточку.
У тебя реквизит номенклатуры - "ОбъединеннаяКарточка"
Для обычных товаров он равен самому "ТекущийЭлемент", в случае фасованного товара - весовому прародителю.


Копируешь отчет в котором нужно консолидировать, и просто заменяешь переменную запроса Номенклатура (Товар) с Товар=ХХХ.Номенклатура на Товар=ХХХ.Номенклатура.ОбъединеннаяКарточка;

Например Ведомость по Остаткам ТМЦ
В запросе меняешь
    |Номенклатура    = Регистр.ОстаткиТМЦ.Номенклатура,      
    |                 Регистр.РезервыТМЦ.Номенклатура;
На |Номенклатура    = Регистр.ОстаткиТМЦ.Номенклатура.ОбъединеннаяКарточка,      
    |                 Регистр.РезервыТМЦ.Номенклатура.ОбъединеннаяКарточка;

И всё...

Восьмерочник в каком-то мире другом живут, этож клюшки ;-)

Не знаю как насчет восьмерочников, а вот в (6) точно написано нечто странное ;)
Зачем оперировать группой? Это как минимум неудобно.
И нужно помнить - по каким карточкам нужно оперировать группой, а по каким нет.
Если всё легко и просто консолидируется во всех отчетах. (и выгрузках).

(71) это любимая фишка семерочнико некоторых, неправильно группы (иерархию) использовать вместо подчиненных справочников или своего реквизита для связи

да так тоже можно, но блин оставлять в руках/правах кривых юзеров такую тонкую вещь??? они же заразы догадаются в другую группу перекинуть...

(72) Да ладно? Никак с семерочниками/восьмерочниками это не связано. Это связано с попытками натянуть на типовой функционал без дописок. Причем без дописок то не выйдет, потому что выгрузку в бухгалтерию в любом случае придется доработать.

(73) В 8-ке штатно в типовых есть доп.реквизиты и сведения и к тому же сча они и хранятся в ТЧ штатно а не как раньше в РС

(74)???
Не понятно к чему это. В семерке штатно есть доп. сведения. И хранятся они в справочнике СвойстваНоменклатуры подчиненном Номенклатуре.
Но использовать его будет не так удобно как (69)

(75) Таки где http://static.1c.ru/rus/products/1c/predpr/trade92/02.gif?
Вот это вот незаметная кнопочка снизу?

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

(72) это запросто.

(76) Кнопка "Свойства"
(77) А сделать легко и просто, введя один реквизит в номенклатуру - что мешает?

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

На свойствах номенклатуры много не сделаешь

Полюбасику все упирается в необходимость количественного учёта, так что скорее всего отдельные номенклатуры делать, а как их связывать с исходным товаром - смотреть по месту как удобнее

Хотя например у нас сейчас так и делается.
Заводится новая карточка в папке и всё...
Документ КомплектацияТМЦ списывает с одной карточки и приходует на другую.
Ну и естественно у всех товаров БазоваяЕдиница - "кг".

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

+ (81) Единственный вариант подмены - реквизит.
Ибо быстро консолидировать (сгруппировать) в семерке можно только по реквизиту, родителю или владельцу.
Владелец отсекается, по родителю ну очень неудобно, и переписывать придется никак не две строчки. Остается только один вариант - реквизит номенклатуры.

(82) Ну или выносить наружу связь в отдельную таблицу (справочник, регистр)

(83) Не совсем понял.
Каким образом ты перепишешь любой отчет, ну например ВедомостьПоОстаткам, если вынес наружу в отдельную таблицу?

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

(84) Мне привычнее ТЗ крутить, запросы для меня это просто способ выдернуть-собрать исходные данные для обработки кодом.
А в ТЗ не проблема заменить номенклатуру и потом сгруппировать.

(85) Еще раз - у тебя уже есть конфигурация, ТИС 9.XX
Тебя просят сделать быстро консолидацию. Тебе либо зарплату платят за это, либо наняли за деньги.
Ты перепишешь все отчеты в конфигурации на ТЗ?

Тут работы на час. Ты перепишешь все отчеты в конфигурации на ТЗ за 5000 рублей?

С множественными фильтрами, динамическими группировками?

Или ты копеечную задачу только что превратил в проект стоимостью в миллионы?

На всякий случай я по пунктам распишу решение этой задачи.
1. Добавляю в справочник номенклатуры реквизит, называю
ОбъединеннаяКарточка, тип "Справочник.Номенклатура"
2. Выношу его на форму.
3. Пишу обработку
спр=создатьобъект("Справочник.Номенклатура");
спр.ВЫбратьЭлементы();
Пока спр.Получитьэлемент()=1 цикл
Если спр.Этогруппа()=1 тогда
Если пустоезначение(спр.ОбъединеннаяКарточка)=1 тогда
   спр.ОбъединеннаяКарточка=спр.ТекущийЭлемент();
   спр.Записать();
КонецЕсли;
КонецЕсли;
КонецЦИкла;
4. Беру пару необходимых отчетов (ВедомостьПоОстаткам,АнализПродаж), копирую как внешние, делаю замену (69)
5. Беру обработку выгрузки в бухгалтерию, и заменяю везде в обращении к ТиС .Номенклатура на . Номенклатура.ОбъединеннаяКарточка

Всё, проект сделан. Можно работать

Можно еще сделать рюшечки, написать простенький отчет который покажет номенклатуру в которой .ОбъединеннаяКарточка не равно .ТекущийЭлемент() и т.д. Переписать типовую КомплектациюТМЦ

А ты во что превратил простейшую задачу?

спр=создатьобъект("Справочник.Номенклатура");
спр.ВЫбратьЭлементы();
Пока спр.Получитьэлемент()=1 цикл
Если спр.Этогруппа()=0 тогда
Если пустоезначение(спр.ОбъединеннаяКарточка)=1 тогда
   спр.ОбъединеннаяКарточка=спр.ТекущийЭлемент();
   спр.Записать();
КонецЕсли;
КонецЕсли;

КонецЦИкла;
//
Небольшой косяк был

(86) Ничего не попутал? Где в задаче в (0) есть требование переписывать все отчеты (чтобы в них была группировка)?

Там группировка только для выгрузки в бух нужна. Складу своды нафуй не сдались, он будет смотреть по остаткам/движениям каждой конкретной номенклатуры.

На сколько старенькая ТиС? ТиС9 или старее?
Самое быстрое и штатное решение такое:
Заводим номенклатуры Сахар 9 кг. Сахар 3 кг. У каждой базовая единица кг, основная пакет с соответствующим коэффициентом пересчета.
Получаем штатные отчеты в базовой единице в килограммах, в основной - пакетами.
Выгрузка в бухгалтерию пойдёт в базовой единице, в кг.
Единственное, что надо будет сделать, это при выгрузке в Бух подменять номенклатуру сахара пакетированного на сахар весовой. Для этого можно реквизит в номенклатуре завести в в обработке выгрузки данных в бухгалтерию одно-два точечное изменение сделать.

(89) там есть задача сверки между базами. Для этого консолидация и нужна.
По-минимуму это и есть два отчета - анализ продаж и ведомость по остаткам (считаем что выгрузка документами, и себестоимость считается в бухгалтерии отдельно)
В случае реквизита - для консолидации в отчете изменяеется одна строка в отчете. Единственное условие для корректной работы - базовая единица в весе (кг)
(90) +100500
Я так понял что 9.xx, восьмая слишком стара

ИМХО никакие килограммы (и даже штуки) в бухгалтерии не нужны и выгружать надо только суммы по документам в разрезе видов НДС.

Т.е. в бух только номенклатура НДС10%, НДС18, НДС0%, БезНДС и все. По сумме по каждому контрагенту и сверять.

А если не нравится то Комплексную пора или УПП/ERP2/KA2

(0) А причина бухгалтерам упираться в кг одни?

(92) расчет бухгалтерской себестоимости естественно сделаешь отдельным проектом?

+ (94) повторюсь, пока задача стоит порядка 5000 рублей, ты же всё пытаешь превратить простейшую задачу в дорогущий проект, уже пошли предложения перехода на другие системы. У тебя точно всё в порядке?

(93) причина одна
Отражать так как в документах поставщика и
Неумение нехотение провести простые операцииипо перефасовке по усету

(96) То есть ты объясняешь абсолютно корректное требование бухгалтеров "неумением" м "нехотением"?
Как ты будешь консолидировать учет по "объединенной карточке" не приводя её к одной единице измерения?
Я уже молчу о том что бухгалтерии как правило нужно нужно знать килограммы.

(94) И так посчитает прекрасно по среднему.

Какая разница считать себестоимость отдельно для "сахар 1" и "сахар 2" а потом между ними среднюю.
Или сразу считать себестоимость для "товар НДС18%".

(97) Бухгалтерам нафик не важно конкретное наименование товара и даже в чем оно измеряется.
Как и количество товара фактически, просто без кол-ва (и цены) не получить себестоимость среднюю.

По сути проблема только в непонимании между бухгалтерами, складом и программистом.

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

Вся проблема в том что бухии слом провести по бу операции перефасовки. И более ничего. Как только бухия это сделает - не надо вообще ничего нигде программить

Посл 50-го поста не читала...
Мне, лично, не нравится реализация единиц в ТиС.
Мысли (не реализовано и до конца не додумано): у номенклатуры есть базовая единица (справочник "Единицы") - кг (по данному примеру). Подчиненный справочник "Единицам": кг -> пакет 3 кг = 3 кг, -> пакет 5 кг = 5 кг. Приход в кг. Расход - по желанию (кг, пакеты). В расходе (при использовании пакетов): пересчет в кг (базовые). То есть: в расходе 3 * пакет 3 кг - пересчет (и проверка, соответственно) в базовые и проведение (списание) 9 кг. В регистре хранится в базовых (кг).
Насчет пакетов - можно и в регистр запихнуть, но надо ли?
Подчеркиваю - мысли, не реализовано.

А в чём проблема сделать как в 10 и 11? Единица хранения отдельно.