Добрый день!
Знатоки типовых конфигураций 7.7, объясните плиз, зачем в ТиС сабж? В чем сокровенный смысл?
Ну, я понял-бы, если-бы был подчиненный "Единицам" справочник "Цены"... Для разных единиц, соответственно разные цены - для единицы "Штука" - 10 руб, для единицы "Десяток" - 100 руб.
Но, зачем такое? Сегодня у цены "Розничная" единица измерения "Штука", а завтра "Десяток", с соответствующим коэффициентом? А после завтра, опять поменяется?
От одного партий-образующего документа к следующему документу-? Но, ведь и другие документы(расходные) обращаются к ценам? Какой-то бардак получается.
Как-то не логично, не понимаю в чем смысл периодичности в данном конкретном случаи...

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

(0) >> подчиненный "Единицам" справочник "Цены"
Тогда бы для каждой единицы пришлось бы вести отдельный прайс. А это для большинства торгашей-ларёчников излишество.

Присоединясь к (1).
Иногда не хватает то, что в штатной конфиге в ценах нельзя сделать
- Оптовая, за шт = 10
и
-Оптовая, за уп(10) = 90

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

(3): решали. размножали классификатор - и соответственно сами единицы. прайсы и ценовые отчеты "допиливали" для сверток по куску наименования.
(4): юзали. причем это ОЧЕНЬ выручало. особенно когда начали в ес продавать.

В общем, почему возник вопрос... Одни мои "СуперПуперЮзвери", каким-то образом умудрились у одних сигарет поставить вручную у цены за штуку сигарет - единицу блок(в ручную, палец в истории). А у единицы блок -коэффициент 10. При этом, сама цена осталась в истории не тронутая, за штуку... Сами понимаете, какой бардак в учете получился, хорошо не очень давно, поправил и последовательность за 10 дней пришлось восстановить, мелочи... А если бы год назад?
Вот я и думаю - конфа хоть и на базе ТиС, но уже далеко не типовая, и по метаданным в том числе... Ни о каких типовых обновлениях речи уже давно нет, одно подчинение ЮрЛиц Контрагентам чего стоит...
Может выпилить к чертовой бабушке это, от дальнейших проблем? Там всего 11 мест в конфе, где конструкция ".Единица.Получить(" находится... Поменять на ".Единица", снять галку "Периодический", и дело к месту... Учет цен вести для базовой единицы, все остальные цены для единиц, с коэффициентом отличным от базовой - получать пересчетом(это в принципе, сейчас так и работает). А если понадобится типа такое - "рубль штучка, 2 рубля кучка, а в кучке три штучки", что само по себе маловероятно(розничные магазинчики, ни о каких доп. прайсах и речи нет), то буду решать через механизм скидок для "кучки"...
Какие еще могут быть подводные камни в таком решении?

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

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

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

Понятно. Я за простоту и прозрачность. Я не вижу никаких проблем. По моим прикидкам - я могу безболезненно убрать периодичность с этого реквизита. И вообще, добавить проверку, что у цены может быть выбрана только единица измерения с коэффициентом 1. Все остальные цены, для других единиц, вполне можно рассчитать через коэффициент.

А вот реквизит "Склад", я бы добавил в цены(естественно - не периодический)... У одного предпринимателя(не важно, ИП, или ЮрЛицо), могут быть несколько торговых точек с разными ценами. Надо подумать, и реализовать такой механизм... Можно иметь кучу разных цен(розничных, естественно) для разных торговых точек. Сейчас посмотрел в типовой ТиС, 1000 релиз, там такого нет, как это не странно...

(9): это конечно в принципе неплохо м.б. - то, что ты не видишь никаких проблем...
я лично навскидку(!) вижу минимум не одну проблему
- ты не нашел и не исправил по всей конфигурации ИспользоватьОбъект("Единица",...); с прицепами различного функционала
- ты тупо не знаешь как себя поведут периодические значения(!) при отключении флага "периодический" - а не потеряются ли все?
не трогал бы ты, а то косяки как полезут - так и сам умаешься и - что главнее - пользователей ушатаешь...

(9) в ТиС вроде как переоценка по складам доступна

(10) - ты тупо не знаешь как себя поведут периодические значения(!) при отключении флага "периодический" - а не потеряются ли все?

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

(10) - ты не нашел и не исправил по всей конфигурации ИспользоватьОбъект("Единица",...); с прицепами различного функционала.

Вот за это, спасибо... Как-то и не подумал, что такое может использоваться... Но: https://content.foto.my.mail.ru/mail/m_w_w/_mypagephoto/h-300.jpg - похоже все-таки не используется.

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

Еще одно пояснение, почему я так этим озаботился. На самом деле, моя "нетленка" написана не совсем на базе типовой ТиС... Она писалась на базе конфигураций "ККС: Магазин". Добавлены, выражаясь языком снеговиков "подсистемы" работы с алкоголем, табаком, еще много разного. Вместо их не поддерживаемого фронта "IS-Market", добавлена полная интеграция с фронтом УКМ-WIN.
А этих конфигураций, на самом деле было две редакции - ред. 2.0 и ред. 3.0. У меня у половины клиентов 2.0, у половины 3.0. Каждый раз переписывать свои обновления под две разных редакции - мне уже надоело, хочу сделать что-то универсальное. Если делать - то на базе 3.0. А там, как раз, в отличии от 2.0 в ценах нет склада и реквизит "Единица" периодический. А есть клиенты, которые имеют по  несколько магазинчиков, и работают под 2.0. Вот я и думаю, как "состыковать не стыкуемое"...

+(13) Пока, изучением структуры метаданных, я вижу только два отличия - это организация справочника "Цены", которая описана выше, и хранение нескольких ШК для одного товара. В ред 2.0 для этого отдельный справочник "Ассортименты", в ред 3.0 все хранится в справочнике "Единицы". Для одного товара может быть много единиц с одинаковым ОКЕИ, но разными ШтрихКодами...
И если делать что-то универсальное, то хранение цен, мне кажется более удачным в ред. 2.0, а справочник Ассортименты я бы выкинул, перенес бы в единицы как в 3.0. Естественно, для этого надо будет написать и запустить обработку переноса перед удалением справочника "Ассортименты". Но, это как-бы не проблема.

(12) ЕМНП ,в документе "ПоступлениеТМЦРозницу" можно сразу установить розничную цену хоть вручном режиме, хоть в пересчете % наценки от закупочной. Единственное неудобство в том, что если остатки хранятся в розничных ценах , следует сделать переоценку розничных цен остатков товаров от предыдущих поступлений.

(15) Это понятно. Но, так, как у справочника "Цены" нет реквизита Склад, то цены будут изменены для всех торговых точек одной фирмы. А это, не всегда удобно. Хотя, как я понимаю, остатки переоценятся только по фирме из документа. Можно их в принципе получать из реквизита "ПродСтоимость" регистра "ПартииНаличие"... Но... Какой тогда вообще смысл в справочнике "Цены", если из него нельзя получить актуальные цены для торговой точки? Например, при выгрузке товара в ОФФЛине ККТ... Из регистра тащить через партию и приходный документ? Ну, это, как-то совсем не комильфо...

(15) следует сделать переоценку розничных цен остатков товаров от предыдущих поступлений.
С этим то как раз проблем нет. Документ "ПереоценкаРозница" создается автоматически при проведении приходной накладной. Но, он переоценяет остатки по выбранному складу, да. Но, сама приходная накладная меняет периодический реквизит "Цена" в справочнике цен, для единственной розничной цены. А она для разных складов должна быть разная. :-(
Так, как хочу я(и как было сделано в ред.2.0), должна быть одна закупочная цена и несколько розничных цен, с одной базовой единицей, отличающихся реквизитом "Склад". Соответственно, переоценка как работала, так и будет работать, а приходная накладная будет изменять только одну из розничных цен, которая действует для выбранного в ней розничного склада...

(17) У астор ТД было решение по учету цен , они переписали их в регистр оборотный в разрезе документа, склада,фирмы и цены

(18) Ну, это тоже имеет право на жизнь... Но, ИМХО сложнее, чем добавить один реквизит и поправить несколько процедур/функций, которые работают со справочником "Цены".
Это в приходе, установка цены, добавить установку склада, и функции глобального модуля, по получению розничной цены. Ну, и соответственно, все места, откуда эти функции вызываются, в параметры вызова функций добавить реквизит "Склад"...
Да, гимороя много... Но, я думаю оно того стоит на будущее. Все равно, когда я готовлю обновление для своей нетленки под разные редакции, мне приходится в десятке мест делать различия для редакции 2 и 3, как раз из-за наличия/отсутствия реквизита "Склад" в вызовах этих функций...

+(19) Тем более, можно это будет вводить не спеша, поэтапно. Добавить реквизит, и в приходе его устанавливать. Он никому не помешает. В расходе и отчетах все будет работать, как и работало(естественно, это надо начинать с тех, у кого не было этого раньше, т.е. ред.3.0, один склад). Потом, добавить в функции, и в расход. А потом, уже отчеты поправить. Естественно, сначала все это обкатать на пробной базе.

(6) "...за 10 дней пришлось восстановить, мелочи... А если бы год назад?"
- да и похрен. как только кто-то обнаружил бы что торгуют как-то криво, цены не те - то и с той точки пересчитать. а если никто не увидел - а) этим товаром не торговали (ну и ок!) б) торговали и всех все устраивало ;-)

(6) "одно подчинение ЮрЛиц Контрагентам чего стоит..." - это ты сам впилил? вроде в Типовой как раз наоборот - одному ЮрЛицу может соответсовать кучу клиентов. для контор где трэш и угар - это самый нормальный способ разделить одного юрика по разным манагерам (например разные направления деятельности, каналы продаж и пр). а то что у контргаента можно делить отношеения посредством договоров - для них это "сложно".

(6) "Может выпилить к чертовой бабушке это, от дальнейших проблем? Там в"
1. в фейсе запрети редактирование единицы в спр.цены
2. вообще закрой интерактивное прямое редактирвоание цен. Сделай док.РегистраторЦен - все только через него.
ну и тд.
..убирать я бы не стал...
так как вы работаете от штуки - то п.1 решит ваши проблемы когда нечаянно или по недомыслию...

(8) "но ломает весь механизм пересчета цен." - а что там ломать? штатно там в ТиСе всего пару мест где пересчет цен. тем более если цены за шт и кор - независимые друг от друга - то и пересчитывать нечего не надо. в глПолучитьЦену()/глВернутьЦену() подшаманить обращение к спр.цены с учетом ед. и все...

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

(9) "А вот реквизит "Склад", я бы добавил в цены(естественно - не периодический)."
- не надо этого делать. Спр.ТипыЦен и Спр.Цены - это СПРАВОЧНАЯ информация для ЗАПОЛНЕНИЯ ДОКУМЕНТОВ.
закрепление конкретных розничных цен за конкретными розничными торгвыми точками выполняется
1. документом перемещение на торг.точку
2. поступлением ТМЦ на точку
3. оприходованием на точке

(12) "У меня документы прихода товара - ПоступлениеТМЦРозница. Они сразу приходуют товар на розничный склад, по розничным ценам, для выгрузки его потом в ККМОффлайн, и загрузки обратно отчетов о розничных продажах. Как-то лишний документ переоценки не вписывается в эту схему..."
- да, все правильно. что не устраивает то?

есть товар в торг.точке на нем ценники = 120руб.
теперь поступлениеТМЦрозница, с розничной ценой = 140 руб.
.
зачем переоценка.
будет два товара, 1 по 120, второй по 140. с разными ценниками. что есть бяка и нарушение.
варианты:
1. доторговываешь товар с ценниками по 120, выставляешь товар по 140.
2. делаешь переоценку ФИЗИЧЕСКУЮ - переклеиваешь ценник с 120 на 140. Этому физ.действию и соотвествует документ.Переоценка - переценил остатки по старой цене на новую, распечатал ценники на КОЛИЧЕСТВО Старого товара из документа. все уже посчитано, конфига сама посчитает.
.
если у тебя товар на точке без ценников (что есть тоже нарушение) и как такового переклеивания ценников не будет - то не ипите себе мозги, откажитесь от склада с признаком "розничный", торгуйте в розницу с обычного оптового склада (переточив самую малость чекККМ, убрав оттуда определение продажной цены из регистра. там модуль формы весь 1200 строк, из них "нужных" для подправки в 2-3 местах. и в модуле документа в 1 месте.

да и то, у меня большое подозрение что ЧекККМ штатно все с оптового склада будет пробиваться (глянул мельком типовую, у моей конфиге доставшейся  внаследство перепиленной по рознице вдоль малость выворочено сделано), достаточно поставить в полномочия кассира - запрет доступа к спр.Цены, обработкам изменения цен (штатным в конфиге) и полномочие "РазрешитьРедактированиеЦенВдокументах" = 0

вот типовой код чека

Процедура ПоКнопкеПодбор()
    
    Параметры = СоздатьОбъект("СписокЗначений");
    Параметры.ДобавитьЗначение(Фирма,           "Фирма");
    Параметры.ДобавитьЗначение(Склад,           "Склад");
    Параметры.ДобавитьЗначение(0,               "ЕстьВидТМЦ");
    Параметры.ДобавитьЗначение(Валюта,          "Валюта");
    Параметры.ДобавитьЗначение(Курс,            "Курс");
    Параметры.ДобавитьЗначение(Кратность,       "Кратность");
    
    Если Склад.РозничныйСклад = 0 Тогда
        Параметры.ДобавитьЗначение("ИзСправочника", "ЦенаВподборе");
        Параметры.ДобавитьЗначение(глЗначениеПоУмолчанию("ОсновнойТипЦенПродажи"), "ТипЦен");
    Иначе
        Параметры.ДобавитьЗначение("Розница",       "ЦенаВподборе");
    КонецЕсли;

Процедура ПриИзмененииШтрихКода()
    Перем ВремТовар,ВремЕдиница;
    
    Если ПустоеЗначение(ШтрихКод)=0 Тогда
        Если ПолучитьТовар(СокрЛП(ШтрихКод), ВремТовар, ВремЕдиница) = 1 Тогда
            Номенклатура = ВремТовар;
            Единица      = ВремЕдиница;
            Коэффициент  = Единица.Коэффициент;
            
            Если глПересчетРегистров(Контекст, СписокПараметров) = 0 Тогда
                Возврат;
            КонецЕсли;
            ТовЦена = "";
            
            Если (Номенклатура.ВидНоменклатуры = Перечисление.ВидыНоменклатуры.Услуга)
             или (Номенклатура.ВидНоменклатуры = Перечисление.ВидыНоменклатуры.Работа)
             или (Склад.РозничныйСклад = 0) Тогда
                
                Цена = глПолучитьЦену(Номенклатура, Константа.РозничныйТипЦен, ДатаДок, Единица, Валюта, Курс, Кратность);
                
            Иначе    // цена из остатков регистра
                глПолучитьРозничныйОстатокЦену(Номенклатура, Единица, ОстаткиТМЦ, , ТовЦена);
                СписокЦен = ЗначениеИзСтроки(ТовЦена);
                Если СписокЦен.РазмерСписка() = 0 Тогда
                    Цена = 0;
                Иначе
                    Цена = СписокЦен.ПолучитьЗначение(1);
                КонецЕсли;
                
            КонецЕсли;

(14) "которая описана выше, и хранение нескольких ШК для одного товара."
- типовая Тис поддерживает это штатно. и "ШК  на товар" - не бывает. бывает ШК на счетную единицу товара.
и не поверишь, в типовой ТиС ШК даже упаковкам и коробкам штатно есть.
только ШК = 13 знаков. в те времена когда писался костяк ТИС 9 редакции. а это было в районе 2000г. никто не думал что ШК - это не только ЕАН ;-)
.
с точки зреняи розницы тповая ТиС сделан просто, но впролне себе. Нету только развесистого скидочного функционала и прчоего аналогичного.
Сегодня как раз со своим процессо-девочкой объяснял ей как сделать скидки в типовой ЧекККМ (а не так как отсосеры нахерачили, бо нихуя не знают толком, по верхам - да, а опыта - мало) и возврат товара проданного со скидкой 9все, блин есть штатное, подпилить малость для удобства, а такие  ваятели "убрать периодичность" типа - нахерачили обход контроля фиксированных цен и прчоего.. вся партионка поплыла, низхера не закрывается толком, а сейчас бало комитентское внезапно считать пришлось и не 1-2 товара адохерища...

(16) "Это понятно. Но, так, как у справочника "Цены" нет реквизита Склад, то цены будут изменены для всех торговых точек одной фирмы. А это, не всегда удобно. Хотя, как я понимаю, остатки переоценятся только по фирме из документа. "

- все неверно!!!
в типовой тис продажные цены "измененяются" для конкретного "фирма-склад" независимо от других кортежей "фирма-склад".

(17) "Какой тогда вообще смысл в справочнике "Цены", если из него нельзя получить актуальные цены для торговой точки?"
- потому что так - хорошо. писал выше.
как только ты впилишь склад в спр.цены - ты сделаешь себе жопу. Потом тебе в спр.цены понадобится впилить Фирму. апотом еще и партию. Бо цены могут быть разные в зависимости от сочетаний Фирма-Склад-Партия и не поверишь! в типовой ТиС - даже статусы партий есть разные - комитентский, собственный и это тоже может быть как доп.разрез для фиксации продажной цены,
.
В тповой ТиС все это уже есть. сделано. и работает. Прорверено.

(17) "Но, сама приходная накладная меняет периодический реквизит "Цена" в справочнике цен, для единственной розничной цены. А она для разных складов должна быть разная. :-("
- это у вас так раком сделано хрен знает в каокй конфиге.
В типовой ТиС цены в спр.цены не имеют никакого отношения к розничным точкам. Я тебе на типовой ТиС могу штатно завсети так что спр.цены - вообще пустой будет. то есть тотально. При этом на каждом складе каждой фирмы будет своя зафиксированная продажная цена, только по которой и сможет пробиваться чек. на nn1 - цена = 100, на nn2 - цена = 105. а в спр.цены - ВООБЩЕ ПУСТО. чудеса!!!

(18) "У астор ТД было решение по учету цен , они переписали их в регистр оборотный в разрезе документа, склада,фирмы и цены"
- что подтверждает мои слова в (30) - про "впилить фирму, партию..."

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

(32)ранняя пташка, или сова? я то хоть от неведомого ОРЗ маюсь бессонницей.

ух понаписал.. чувствую себя ахеренно умным.. ;-)
просто злой я последние две-три недели из-за резгребания гуана... в рознице как-раз.. из-за писателей нетленок... уффф...
сорри если что не так

(35)розница на клюшках до сих пор?

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

на самом деле можно все проще сделать. но надо чтобы пипл товаровед/учетчик вменяемый сидел "на базе". а с этим - плохо. Оперативные процессы норм идут, но мусора понднакопилось, да и исполнительская дисциплина хромает ну и тд.
и еще интересные подходы.
товар отдают на валдберз по комиссии - ну ка кобычно. заявы - ааа блин торговля в убыток!!! вычистили гуано. нормальная торговля. в доход. где убыток?
а убыток считаетс яочень просто - отдали вайлдберизу товара на 1000руб. в продажных ценах сторговал валдбериз по себестоиости на 100 руб, по продажной стоимости 200 рублей. вроде доход 100% руб, ан нет - убытоке, бо 200/1000 = 0.2 = 80% убытка (пусть дае база не 1000 руб продажная, а 500 себестоимсоть - все равно убыток). я аж ахирел. не, конечно и такой вариант расчета имеет право на жизнь, только я говорю - так у вас товар на конторе неликвида лежит на миллион по себестоимости. с таким подсчетом у вас бизнес вообще в глубокой ж. - а в ответ - тишина...
.
не. я конечно не бузинесмен, могу и лажать...

Привет. Все, что ты написал, правильно, и я это понимаю прекрасно. Но:
1. У меня не типовая ТиС, я уже писал. Досталось мне "тяжелое наследство" от ККС. Там все уже до меня было перехерачено, как смогли. При чем, первый вариант - ред. 2.0, была, как я понял, еще на основе 8.7 сделана, потом, такое ощущение, что прогеров разогнали, и уже другая бригада сотворила аналог на основе 9.2, с нуля, частично перенеся наработки из предыдущей редакции. При этом, добавили туда несколько новых механизмов, связанных с интеграцией с их, тогда еще актуальным фронтом. Некоторые механизмы не перенесли из ред. 2.0, просто похерили... Все свои "нововведения" защитили ВК с ключем "Катран", спрятав в эту ВК часть функций.
2. Все это они благополучно бросили, по сути, послав клиентов на три буквы, еще где-то в 2011 году, вообще похерив это направление... А я тогда уже был плотно завязан на поддержку этой конфы, бросить клиентов не смог, так и продолжаю по сей день. А половина клиентов сидит на ред. 2.0, половина на 3.0...
3. ВК вместе с Катраном я выпилил(а как иначе? поддержки 0, нет уже ни тех программистов, кто эту ВК писал, да и сам катран бросил эти ключи, когда чего-то не так - спрашивать не с кого), переписав все функции на 1С. Все работает, даже почему-то быстрее работать стало, хотя казалось-бы, функции С++ компоненты должны быстрее работать, чем аналогичное на 1С, но, как оказалось - нет...
4. Никаких касс под 1С у меня в этой конфе нет. Вообще. Только ОФФ-лайн обмен, по схеме бек<==>фронт. Так уж у них было устроено, что многое в ОФФ-лайн обмене, завязано на справочнике цен. Еще с редакции 2.0, где в этом справочнике был реквизит "Склад". Когда очередные "халтурщики" переписывали конфу ред. 3.0 на основе 9.2, то весь механизм работы с ОФФ-лайн ККТ в части цен, оставили от ред. 2.0, но, про то, что у одной фирмы могут быть несколько складов(розничных магазинов) с разными ценами - даже и не подумали. Поэтому, механизм типовой ТиС, тут работать не будет, а свой, в принципе вполне нормально работающий в ред. 2.0 механизм разных цен по складам - они похерили.

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

Конкретно по тем-же сигаретам: они продаются у меня по МРЦ из кода DataMatrix на пачке или блоке. Во фронте настраивается, приоритет - цена продажи из базы, из ШК, или на выбор пользователя. Я использую из ШК.
Потом, при закрытии смены в 1С и загрузки продаж из фронтов, происходит автоматически переоценка, если сигареты продавались из разных партий, например:
в базе числилась позиция по 100 руб., в количестве 10 штук. Пришла новая партия, еще 10 штук по 110 руб. Старые переоценились автоматом, стало числиться 20 по 110 руб.
На кассе, в течении смены торговали, без разбора, старыми, новыми - в перемешку, по МРЦ из ШК DataMatrix пачек. В результате, продали 5 по 100 руб, и 5 из новой партии по 110 руб.
Вместе с ОтчетККМ формируется переоценка, которая переоценяет в базе эти старые 5 пачек обратно до 100 руб, и списывает их в отчете ККМ, и так-же списывает 5 пачек по 110 руб.
Все закрывается, все красиво.
Это снимает полностью проблему - "типа, пока старые не продали, новые не выкладываем" :-) ... А это, у многих, в других системах есть.
Но, представим, что под прилавком завалялась еще одна пачка этих-же сигарет по старой цене в ШК, 100 руб., не учтенная(ошибки никто не отменял), и продали(фронт не контролирует остатки!) в эту смену 11 пачек по 100 руб, и 5 пачек по 110 руб.
При закрытии смены будет сформирован автоматом еще один документ - оприходование излишков. Он доприходует проданную "лишнюю" пачку по новой цене(можно было-бы приходовать сразу по старой цене, но вдруг нужно будет приходовать и новые, по 110 тоже лишняя пачка вылезла? А в одном документе прихода, не может быть один и тот-же товар двумя строками по разным ценам). А переоценка, переоценит 11 пачек обратно до 100 руб. Все красиво закроется, все довольны, покупатели не в обиде, им продали, все что они хотели(ладно сигареты, они спрятаны, но предположим, это не сигареты, а что-то, что на витрине лежит, они ухватили и хотят купить, а им бы сказали "а не можем продать, у нас по остаткам в базе нет этого товара, касса не пробивает!", если бы остатки контролировались на кассе), а откуда взялся лишний товар - пусть потом менеджеры разбираются, в рабочее время, кому по рукам настучать за это надо.
Вот так это все работает, уже много лет, клиенты привыкли, всех все устраивает... И переходить на что-то новое... Ну... Сложно очень.
Не устраивает только меня - "зоопарк" конфигураций, разных редакций, с разными особенностями. Которые мне все тяжелей поддерживать приходится. Потому, что все мои "подсистемы" плотно завязаны на объекты конфигураций. Поэтому и хочу, собрать в кучу из ред 2 и ред 3 что-то универсальное. А различие по метаданным, я выше описывал, их не так много, но...

(39) Спсб за пояснения!
Сорри, только не понял
"В результате, продали 5 по 100 руб, и 5 из новой партии по 110 руб. Вместе с ОтчетККМ формируется переоценка, которая переоценяет в базе эти старые 5 пачек обратно до 100 руб, и списывает их в отчете ККМ, и так-же списывает 5 пачек по 110 руб."
- здесь 100 и 110 руб - это цена продажи, пробитая в чеке? если да - ну продали по разной продажной цене и продали. зачем что-то переценять? тем более как ты переценишь то что уже продал, какую цену ты поменяешь в уже проданном? и тем более если у тебя продажная зафиксированная цена - ДО собственно факта самой продажи - не является измерением регистра (как в типовой ТиС). а построен контроль как ты говорил на основе спр.цен - то после продажи не пофиг что там в справочнике? Или я что-то не понял? Поясни, плиз, каким образом в твоей конфиге продажная цена попадает в чек и как контролируется указание цены продажи в чеке? 9я думаю что вряд ли кто будет проверять по какой цене СВЕРШИЛИСЬ продажи по факту. "Переоценку" делают обычно для того чтобы на ценниках было одна цена. А если уже продано - то не пофиг что там было на ценниках.?

(22) >> то что у контргаента можно делить отношеения посредством договоров - для них это "сложно"
Это перекладывание проблемы на бухгалтерию. У бухов один договор, в рамках которого нужно 62.1 62.2 правильно делать и счета-фактуры на аванс выставлять.
Для ТиС это не так важно, объединять договора можно на этапе выгрузки в бухгалтерию, но всё равно плодить договора - вариант с хорошими недостатками.

(40) - здесь 100 и 110 руб - это цена продажи, пробитая в чеке?

Да. Цена в чек попадает из ШК DataMatrix на пачке, это МРЦ(в случае сигарет - это МАКСИМАЛЬНАЯ розничная цена, в отличии от алкоголя, где та-же аббривиатура означает МИНИМАЛЬНАЯ розничная цена). На кассе продается, по чем продается. В случае сигарет - если на пачке написано МРЦ 100 руб., то и продать мы не имеем права по 110, хоть в базе остатки у нас и переоценились вместе с новым приходом, и все сигареты этого наименования числятся по 110. Все равно продаем по 100. Такой "закон", иначе могут "дрюкнуть" по полной...
Дальше. Продажа на кассе, ничего не списывает в базе 1С. Это отдельная программа, вообще не 1С. В моем конкретном случае - вот: https://olegon.ru/showthread.php?t=31421
Но, все, что продалось за смену - попадает в 1С после закрытия смены на кассе, через файловый обмен(в моем случае - XML). И дальше начинается свистопляска - в отчет ККМ попадают две строки одних и тех-же сигарет с разными ценами продажи, 100 и 110 рублей. Но, в базе то они числятся всей кучей по 110, после последнего прихода! Вот по этому и приходится переоценять в базе то количество, которое продалось по 100 рублей. Учет то идет в ценах продажи... Иначе напишет "у вас нет товара в количестве Х по цене 100 рублей."... А так, переоценка, автоматически сформированная и проведенная перед отчетом ККМ решает эту проблему. Естественно, она переоценяет только остатки, в количестве нужном для правильного проведения отчета ККМ. Справочники переоценка не затрагивает, справочно, как была установлена цена 110 руб. последним приходом, так она и остается.

+(42) В случае сигарет - если на пачке написано МРЦ 100 руб., то и продать мы не имеем права по 110
Кстати, в отличии от алкашки - сигареты мы можем продавать дешевле МРЦ. Только смысла нет... И так по сигаретам маржа в среднем 7%... Это "курам на смех", в основном, сигареты в ассортименте держат именно из-за ассортимента, прибыли от них никакой... Но, они косьвенно  повышают доход магазина - будут два магазина продуктов рядом стоять, в одном есть сигареты в другом нет... Естественно, покупатель, которому нужны продукты и сигареты - пойдет в первый, и оставит там деньги за продукты, которые мог бы оставить и во втором...

(41) "У бухов один договор, в рамках которого нужно 62.1 62.2 правильно делать и счета-фактуры на аванс выставлять"
- и что? если ты отношению с юрлицом делишь посредством оформления 2-х разных карточек клиента на одного юрлица и пишешь у каждого клиента "основной договор" - то в ТиС - это совершенно отдельные линии учета. и 62.1. и 62.2 по каждой из этих в ТИС ведетяс отдельно. Точно также если на одного клиента завести два договора - аналогично две разные линии. так что заводить два клиента или два договора - одновалентно, но два договора удобнее с точки зрения оперирования разными отчетами, просто легче собирать.
.
а вот если надо чтобы в ТИСЕ были две разные линии учета, но одна линия учета 62 то тут еще надо подумать... Опять же зависит где ведется учет "по 62". например у меня в торговой базе все ведется - и авансовые счф и прочее и долги и прочее по клиентам.
.
а у кого-то может торговля тупо для чисто торговой деятельности - контроля товародвижения и выписки сопроводительных документов, в ТИС - 2 направления, а в бухии у них линия "62" строится одна, потому как договор из ТИСа в бухию приходит и в бухии синхронизируется ПО НАИМЕНОВАНИЮ. и два разных договора из ТИСА на одного клиента в бухии успешно автоматом склетяс в один. как с 8-ой синхронизируется - хз.
.
короче я тут много понаписал, половина может хрень полная - мутноватый я с утра (в ночь базу пересчитывал за 1г4м всего 23 "критичных" ошибки - це успих!) - схемы учета - их удобство и конкатенацию (словто какое!) с бухией - надо продумывать заранее и тщательно. опыт показывает что этим никто особо не заморачивается, пилят по ходу... "хрен ли думать, трясти надо!"

(42) "Но, в базе то они числятся всей кучей по 110, после последнего прихода! Вот по этому и приходится переоценять в базе то количество, которое продалось по 100 рублей. Учет то идет в ценах продажи... "
- ну так вот меня и интересует !!_как именно "числятся"__!!..? каким именно образом "зафиксирована" розничная цена, по которой ПЛАНИРУЕТСЯ ПРОДАВАТЬ? какой именно механизм в конфигурации обеспечивает выдачу сообщения "у вас нет товара в количестве Х по цене 100 рублей"...? - как прога твоя это определяет, откуда она берет данные что по такой то цене есть столькото товара?
.
зы: если отбросить как нсеущественное то что по НПА должна быть одинаковая розничная цена, то в типовой тис - если мы принимаем решение что надо торговать по одинаковой цене - то "фиксация" это йодинаковой цены если были разные цены - выполянется именно переоценкой - движение по регистру - списываем старую аналитику учета "100руб" и пишем новую аналитику "110" руб. Иначе при продаже тупо  или вылезет сообщение "нет по цене ХХХ" или если отключить такой контроль" - регистр будет незакрытый по аналитике "ЦенаПрод"

(45) зы: если отбросить как нсеущественное то что по НПА должна быть одинаковая розничная цена

Ну, это я уже написал почему не прокатит именно с сигаретами... Тот, кто придумал для сигарет МРЦ, я думаю тоже посчитал НПА несущественными... Но... Куда тут денешься. Сигареты спрятаны в магазинах за "шторки", и их цены написаны на самих пачках, с завода, типографским способом... Куда от этого денешься. И в реальной жизни, ни как не получается, что-бы они были по одной цене. Если только уценять более дороги до более дешевых, а потом, когда дешевые кончатся, возвращать цену обратно... А это себе в убыток, так как маржинальность и так на них ничтожна...

(45) нет товара в количестве Х по цене 100 рублей"...? - как прога твоя это определяет, откуда она берет данные что по такой то цене есть столькото товара?

Честно говоря - даже не задумывался. Могу посмотреть...
А хотя... А чего в этом такого? Вот, регистр: https://content.foto.my.mail.ru/mail/m_w_w/_mypagephoto/h-301.jpg
Измерение "ЦенаПрод"(число, не справочник!) есть, ресурс "Количество" - есть... Значит не трудно при проведении документа ОтчетККМ увидеть цену, по которой остатки числятся. Они ВСЕ ПО ОДНОЙ розничной цене в базе 1С числятся, по последнему поступлению... Вот тут, как раз и реквизит склад(измерение регистра ОстаткиТМЦ, в данном случае) пригодится. Так, как на разных складах остатки могут по разным ценам числиться. Но, это и так работает, я туда даже и не лез вообще. Справочник цен, в данном случае носит вспомогательный характер - для упрощения выгрузки на кассу например, и т.п. функций... И даже если его грохнуть совсем, ты правильно выше заметил - на учет это не повлияет. На него даже ссылок в базе нет. Если случайно пометить на удаление элемент справочника "Цены", он удаляется... Но, потом, на кассу этот товар не выгружается, обработка выгрузки ругается "Товар ХХХ не выгружен из за отсутствия розничной цены!"...
Не я это делал, так и було... Ломать и переделывать как-то по другому - не вижу смысла, все и так красиво работает, с текущей задачей справляется.

+(46) Ломать и переделывать как-то по другому
А по другому - это получать розничную цену из регистра остатков... Ну, да.. Можно конечно... Но, смысл?

(45) откуда она берет данные что по такой то цене есть столькото товара?

Мы наверное тут не поняли друг друга... Весь товар числится по одной, последней цене, весь текущий остаток, по 110. И на момент закрытия смены, по 100 рублей - остаток 0. Остаток по 100 рублей появляется на долю секунды, в количестве продажи по этой цене, с момента проведения переоценки до момента проведения ОтчетаККМ, который списывает этот остаток по 100, сколько продалось за смену по этой цене, и остальное по 110, сколько продалось по этой цене.

+(47) получать розничную цену из регистра остатков...

Тут тоже не все гладко... В этой схеме взаимодействия с кассой в режиме ОФФ-лайн, есть нюансы...
Можно грузить на кассу товары из остатков, а можно вообще весь товар из справочника "Номенклатура". И если в первом случае можно взять розничную цену из регистра, то во втором, так не получится. Вот для этого и нужен справочник цен по любому... https://content.foto.my.mail.ru/mail/m_w_w/_mypagephoto/h-302.jpg

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

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

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

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

PS На пробной базе выпилил периодичность единицы из цены... Как не искал - 11 мест только было...
Вроде, тестировал во всех возможных режимах - полет нормальный.

+(51) Как не искал - 11 мест только было...

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

(46)  хотя... А чего в этом такого? Вот, регистр: https://content.foto.my.mail.ru/mail/m_w_w/_mypagephoto/h-301.jpg[?]
- угу, это типовой Регистр.остаткиТМЦ из типовой ТиС 9.2, на этом регистре и построен учет в рознице по продажным ценам.

(47) в типовой ТиС имено так и сделано. здесь надо оличать Розничную цену из регистра остатков - которая обозначает по какой продажной фиксированной цене товар будет пробиваться на кассе на конкретном розничном складе-фирме. Именно этим механизмом обеспечивается возможность иметь разные продажные цены для разных точек. итд.
А розничные цены - про которые обычно говорят лавочники - они имеют в виду Розничные цены из Спр.Цены, ориентируются на них. бо они как темные люди - раз радиоволны нельзя пощупать то и радиовещания невозможно. напрямую -зафиксированные цены в регистре не видят - поэтому танцуют от справочника часто. Это я называю первым нулевым уровнем автоматизации.

(49) " то во втором, так не получится. Вот для этого и нужен справочник цен по любому... https://content.foto.my.mail.ru/mail/m_w_w/_mypagephoto/h-302.jpg[?]

А выгружать чисто остатки - спорный вопрос... Товар может заваляться в зале, но на остатках его уже нет(человеческий фактор)... И что, покупатель, который его "откопал" на дальней полке, должен страдать из за наших ошибок учета?".
- ну так завалятьс может и миллион-полтора и потеряться. а у нормального хозяина если что и заваляется, то погоды это не делает. у меня у лавочника в справочнике товаров под 150 тыс отдельных товаров, на точках от 2 до 8 тыс товаров и весьма редко бывает что в зале товар есть, а в в базе нет (ране были такие вопросы, порядок навел лет восемь назад - так и работает ок). с офиса формируются потсвки на точки. маркируются, перед этим сортируются по точкам под счет через спецарм сортировки с голосовой озвучкой и прочим. на точках - приемк атоже исклдючительно по ШК, ну итд как обычно.

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

(50) "что-то переоценивать-это изобретение ненужного велосипеда,так как все эти переоценки никому не нужны." - по большому счету - да.

// правда пока так и не разобрался зачем на розничном склад в типовой ТиС дублируется учет тоже в разрезе ЦенаПрод - кто-нить в курсе?

(57) в бухгалтерит учет ведется в разрезе количество-стоимость,вот и здемь пвтаются его же использовать.

+(51) Вроде, тестировал во всех возможных режимах - полет нормальный.

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

УстановитьРеквизитСправочника(Цены.ТекущийЭлемент(), "Единица"

Пофиксил :-)  Теперь уж точно все...

(59) в типовой ТиС - такого нет. в типовой при проведении нигде цены не устанавливаются таким вариантом.

это уже ручные дописик или особенности спецконфы

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

У меня практически типовая ТИС ред. 9.2. Тоже используется ККМ оффлайн с разными ценами на разных точках (разных Фронт-офисах).
Но я не рискнул менять так сильно структуру метаданных, чтобы в Цены добавить реквизит Склад.
Я просто использую для каждой торговой точки свой Тип цен https://ibb.co/yXNxmZs

(43) А вот зачем тут переоценка? Все правильно, значение цены в спр. Цены это ПЛАН (планируемая для продажи цена). По ФАКТУ она может быть другая, поэтому при загрузке из Фронт-офиса в документ ОтчетККМ попадает ФАКТическая цена, которая (при определенной "учетной политике") оседает в регистр. А величина отклонения ПЛАНА от ФАКТА в документе отражается как СКИДКА (а не переоценка): https://ibb.co/Dk0PWMc

(45) "Иначе при продаже тупо  или вылезет сообщение "нет по цене ХХХ" или если отключить такой контроль" - регистр будет незакрытый по аналитике "ЦенаПрод""
Чтобы этого не было у Склада убирают флаг "Розничный склад".
При этом вырубается некоторый учет в продажных ценах.
Напр, вместо ПоступлениеТМЦРозница приходится использовать ПоступлениеТМЦ, в котором нет удобного механизма розничного ценообразования.
Я в документ ПоступлениеТМЦ добавил возможность этого ценообразования https://ibb.co/Rz45Yd4
А также допилил несколько отчетов https://ibb.co/cbHF6p0

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

чувствую, нарубится бабла немножко.. ;-)

(66) В моем примере как раз "торговые точки как точки продаж". Но в данном случае роли не играет - самостоятельные они или нет. Это за пределами обсуждаемого примера.
По поводу "розничного" склада. В грубом приближении так: если используется встроенный в ТИС фронт-офис (напр. документами ЧекККМ), то склад "Розничный" и нужен контроль цен при продаже, если фронт - внешний, то "розничный" склад будет мешать.
Но для встроенного фронта + "розничный" склад в связи с возможностью использования МРЦ из ШК товара не так однозначно. "Розничный" склад будет "мешать" продавать такой маркированный товар. Но хоть это исключение, чем правило, но при условии минимальных переделок типовой ТИС от "розничного" склада, скорее всего, придется отказаться (для всего товара, а не только маркированного).

(68) Контроль цен при продаже он для чего нужен? чтобы кассир оперировал фиксированными ценами. каким образом цены зафиксированы - через регистр или как-то иначе - главное чтобы было невозможно их произвольно менять. И тут пока не особо понятно преимущества использования ЦенаПрод супротив Цены из справочника. единственное что с регистром проще данные собирать...
?

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

Вообще, справочник цен - не для хранения каких-то ресурсов, он "справочный", должен использоваться только для "автоподстановок" (в документах, в отчетах).
Хранимые значения цен, остатков и пр. нужно извлекать из регистра.
Если в АТТ учет ведется в продажных ценах, то используется измерение ЦенаПрод, если по себестоимости, то он не нужен.
Для чего нужен учет в продажных ценах? Чтобы при инвентаризациях ларька недостачи (да и излишки) вешать на подотчетников в продажных ценах, а не по себестоимости. Можно конечно рассчитывать динамически подотчет по справочнику "Цены". Но не будет работать если на подотчете есть наименования товара с разной розничной ценой продажи (например, сигареты).

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

(71) Если регламентом запрещены остатки одного товара по разным розничным ценам, то хватит и спр. Цены.
У меня по такому принципу товарный отчет построен https://ibb.co/cbHF6p0
Вычисляет заодно, скидки/надбавки, наценки/уценки, а также сообщает о нарушениям регламента (напр. пришла партия по новой Розничной цене, а пользователь забыл или неправильно сделал переоценку имеющегося остатка со старой розн. цены на новую).

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

(73) Если к нему добавить "Кассовый отчет", то получится полный подотчет магазина. Продавец сдает в конце дня товароведу.
Заодно контроль собственных ошибок, если нач. ост. и кон. ост. не сойдется, товаровед отчет не примет.
Дисциплинирует продавцов, вовремя делать переоценки, контроль за скидками (есть персональные скдики у покупателей).

(74) хм. а разве подотчет торговой точки - это не отчет ккм - кассовая лента отчета + деньги согласно отчету. ни и возможно дополнительно - отчет по чекам в части соответствия цены чека-скидки текущим ценам.
не?

Да... Интересную тему "в период самоизоляции" я затронул...

(63) Но я не рискнул менять так сильно структуру метаданных, чтобы в Цены добавить реквизит Склад.

Ну, отказ от учета по розничным ценам и от документа "ПоступлениеТМЦРозница", это не меньшее "перепахивание всего"...

Как уже неоднократно выше заметили, справочник "Цены" - лишь вспомогательный, для удобства заполнения документов, отчетов, и в моем случае выгрузки в ОФФ лайк ККТ...
Все равно учет цен идет в регистрах, в том числе и по измерению Склад.
Так, что - сильно я учет не поломаю изменением этого справочника. Надо только внимательно добавить, ни где не пропустить...
А переделывать весь учет, как Виктор предложил... Ну, не готов я сейчас... Изменение вспомогательного справочника "Цены", ИМХО процедура на много безболезненнее.

(76) я чего-то не пойму
"Все равно учет цен идет в регистрах, в том числе и по измерению Склад."
- зачем тогда что-то пилить в Спр.Цены? или мы про оффлайн ККТ? в которую тупо выгружаем и все?
так и выгружать по данным регистра... не?

или тупо выгружать цены для всего справоячника товаров по принципу "мало ли что найдется на точке"..?
а учет по продажным ценам - он сугубо для бэкофиса? - если это так то учет по продажным ценам в бэкофисе с регистром - нафиг смысла не имеет.

(78) или тупо выгружать цены для всего справоячника товаров по принципу "мало ли что найдется на точке"..?

Ага... Но, так уже есть, всех устраивает, и менять это... Ну, как-то не охота...

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

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

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

(80) Ну, вот... Радует, что к 80+ сообщению, мы все-таки поняли друг-друга... Жаль, чуть до сотки не дотянули :-)  Я думаю, больше по сабжу обсуждать нечего, можно и закрыть. Хотя... Сама утонет.

(75) Подотчет это остаток (товаров на складе и денег в кассе), а кассовая лента это оборот, а не остаток.

(76) "отказ от учета по розничным ценам и от документа "ПоступлениеТМЦРозница", это не меньшее "перепахивание всего"".
С чего это?
В ТИС в штате предусмотрен режим работы розницы со снятым флагом "Розничный склад". В штате, ничего переделывать не надо, даже документ ЧекККМ и выгрузку/загрузку ККМ оффлан.

Ну, я немного допилил ПоступлениеТМЦ чисто косметически и для удобств, никак не меняя структуру учета и логику проведения по регистрам и справочникам. Можно было и не допиливать, и без этого работало.

(78) Ну, а смысл?
Во-первых, кардинально (т.е. полностью) переписывать выгрузку во Фронт.
во-вторых, фронт всё равно не поддерживает работу с разными ценами на остатках одной номенклатуры. В итоге что даст переписывание? Одну цену мы выгрузим и стандартной выгрузкой по спр. Цены.

(81) Нет. Основной смысл применения измерения ЦенаПрод в регистре иметь РАЗНЫЕ цены одной номенклатуры на ОДНОЙ и той же точке. Т.е. реквизит Склад в спр. Цены тут никак не поможет.
А если нужно хранить РАЗНЫЕ цены на РАЗНЫХ точках, то можно не добавлять реквизит Склад в спр. Цены, а использовать имеющийся разрез (выше писал про разные Типы Цены)

(83) Щас догоним до сотки ;)

В "штате"...
У меня далеко не в штате... Очень много завязано на доке "ПоступлениеТМЦРозница". И из ЕГАИС данные в него попадают, и декларации на него смотрят, и приход "из воздуха" товара, который "завалялся в дальнем углу" тоже через него сделан.
А с добавлением в цены складов, переделок много не будет. Саму функцию ПолучитьЦенцПродажи, функцию ВернутьценуПоТипу, ну и добавить параметр во все места, откуда они вызываются. Мне видится меньше трудозатрат...

(88) Ага...

+(89) Очень много завязано на доке "ПоступлениеТМЦРозница".

И ЭДО туда-же... Печать новых ценников, загрузка данных в весы и ККМ. Все оттуда. И все это переделывать на "ПоступлениеТМЦ", ну ох как лень...

(89) Я то про типовую ТИС и свой Обмен ЕГАИС и алк.декларации, которые поддерживают разные опции (в т.ч. ПоступлениеТМЦ / ПоступлениеТМЦРозница).
У тебя дописка на базе ТИС. Т.е. мы немного с разных колоколен вещаем ))
Но добавление/недобавление реквизита Склад в спр. Цены никак не влияет какие виды документов используются.
Пока сводится к тому что либо добавляем реквизит Склад, либо используем имеющийся разрез ТипЦен, который можно использовать шире, напр. для многофирменного учета, кода разные не только склады, но и фирмы. Нужно лишь сделать служ.связь между отбором Фирма+Склад и ТипЦен.

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

Да я же говорил... Не я это изначально начинал писать, а в ККС несколько бригад, в разное время. Мое там только алкоголь, ЭДО, и взаимодействие с новым типом ОФФлайн ККТ, взамен ККСовского АРМа, поддержку которого бросили. Все остальное - тяжелое наследие....

(93) да у всех клюшечников так наверное ;-)

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

(95) единица измерения услуги = 1 коп. количество = 10000 , цена за 1 коп = 1 коп, сумма = 100руб.. ;-)

(92) C "полный бред" не согласен...

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