Завел в типовой бухгалтерии 7.7 ред. 4.5 субконто с нетрадиционным типом: Число, длина 15, точность 2.
Но почему-то при записи операции точность теряется и значение субконтно в проводке округляется до целого.
Например, в форме операции указываю значение субконто 50.53, а в проводках "оседает" значение 51.00.
Как побороть сабж?

Почему при записи числа в субконто происходит округление?

"В качестве видов субконто в системе 1С:Предприятие могут выступать доступные в системе типы данных, кроме дробных чисел и строк длиннее 20 символов.
"
(c)ЖКК

(2) Значит будет у меня субконто типом "Строка", а не "Число".
Не скажется ли это негативно на системе: медленная обработка такого субконто? Рост размера файла, хранящего движения и остатки в разрезе такого субконто? Или тут все штатно как и с субконтами типа Справочник или Документ?

(3) Позволь полюбопытствовать?
Зачем сударь вам сей изврат?

+ Обычно в субконто справочником приправляют, для ведения аналитики :)

(3)Насчет размера - надо сравнить вес ссылки на агрегат и на твою строку, не думаю, что стОит об этом париться...
Что такое "обработка такого субконто"?

(4) Хранение остатка отгруженной залоговой тары в разрезе залоговой цены.
(6) "обработка такого субконто" - проведение документов, создающих проводки с данным субконто.

(0) я делал справочник, Числовое субконто. В строковый код его писал число, устанавливал в проводки через глобальную функцию, которая определял есть ли такое "число", если нет то создается новый элемент справочника. числа были в диапазоне от 0.1 до 100. так что всего 1000 возможных вариантов. на деле использовалось штук 100 наверное

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

(7) Чего хранение?
И для этого нужно использовать субконто? О_О
Забалансовый счет уже нельзя добавить? :)

(9) Отборы по этому субконто не нужны.

(10) Я завел забалансовый счет с тремя субконто: Договор, Номенклатура, Цена. Цена это как раз сабжевое субконто.

(7) можно хранить цену, умноженную на 100. с отчетами только повозиться придется

(13) Можно, но тогда лучше хранить в строке, будет красивей.

(11) >> Отборы по этому субконто не нужны.

тогда и субконто само не нужно

Я думаю если подумать, то можно найти более элегантное решение, чем лепить такой трешь как субконто в виде числа.

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

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

(15) Что такое отборы?
Отбор нужен, но не нужна оптимизация отбора. Я отвечал на (9), но одно слова выпустил.

(17) Не пойдет. Создается лишняя сущность без надобности.
(18) Какой выигрыш дает такая реализация?

(20) ну да конечно. не создаем лишнюю сущность. но делаем через ЖПО.

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

(21) Почему ЖПО? Кто сказал что тип субконто должен быть только Справочник/Документ/Перечисление?

(17) Скорей всего даже справочник Тары, а цену уже организовывать исходя из справочника тары. :)

(22) Потому, что Цена на тару А1 и тару Б2 одна и та же :)

Но фасовка разная и разные цеха

(23) Тара в основном одна и та же. Но отгрузили ее по разным ценам в разное время. Дробная цена вообще была не предусмотрена, но возникла из-за ошибок учета, когда бухгалтер не пойми что писал в накладных, поэтому наряду с номральными ценами тип 50, 57, 60 руб. Возникли и нелепые цены: 50.2, 50.37, 50.51 и даже 6815.45(!). Вводится учет на забалансе "задним числом" и поэтому все эти огрехи вылезут в начальных остатках на третьем субконто. После этого желательно провести сверку с клиентами и остатки поправить с целью уничтожения остатков по неверным значениям субконто. Если пойти по пути создания справочника для хранения цен, то он просто будет из себя представлять помойку. Которую еще потом придется вычищать когда (если?) будет наведен порядок в разрезе залоговых цен.

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

(26) А что ты будешь делать ,когда появится еще одна тара?
Субконто № 4-ре добавлять? :)

(27) Потому что тара подлежит возврату. И нужно выяснять может ли покупатель вернуть нам тару в таком в кол-ве и по такой цене.
А то ведь нашлись ушлые, которые получили у нас давно тару по цене 60 руб, а теперь пытаются вернуть по 80 руб.
И даже есть такие, которые купят ведра где-то на стороне и пытаются нам ее впендюрить как возвратную.

(28) Повнимательней, пожалуйста. Номенклатура тары у меня учитывается на 2-ом субконто - см. (12).

(29) А по какому признаку ты различишь тару за 60 р и Тару за 80 р, в программе?

(30) Понятьненько... :)
Просто сея конструкция лучше бы себя чувствовало по регистрам, нежели в счетах :)

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

+(31) Ну я к тому, что физически тара то будет без маркировки...
Т.е. неизвестна дата отгрузки и соответственно и цена... по остаткам, т.е. по конечному сальду :)

+ Или маркеровка тары у вас тоже есть?

+ Даже если закрывать тару по ФиФо, то непонятно, когда ушла первая тара за 60 и когда вторая за 80 :)
Не обороты же ты будешь вечно анализировать, долго это все :)

(31) Ее не нужно различать. Это забота покупателя. Наша задача не допустить перевозврата тары сверх отгруженной.

(32) Предлагаешь добавить мне в бухгалтерию регистры? Даже не смешно.

(37) Напротив... покупатель может тару за 80-ть замышить...
А вернуть как бы за 60 но у вас она пройдет за 80... :)

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

(38) Если можешь, то добавь... легше будет :)
Если особенно это SQL БД, то прямые запросы куда проще строить по регистру :)

(39) Ради бога - его проблема. Вся невозвращенная тара ставится в долг покупателя и подлежит оплате. Пусть покупатель сам решает, что ему выгоднее - отдать тару обратно или заплатить за нее деньгами.

(40) Я к тому, что не цену тары тебе нужно хранить, а сумму за всю тару + там же количество :)
Но и дату отгрузки тоже нужно, как в (33), подобие партионный учет, но по таре

(41) Мне и так не тяжело. Не вижу смысла нагибать контору на приобретение оперативного движка.

(41) В бухгалтерской базе регистры лучше не использовать. Они может и шустрее, но для бухгалтера удобнее проводки по забалансу.

(42) А какой у вас период возврата тары?

(45) А бухи разве поймут, что есть что?
Ну тогда только формировать некий справочник "Партии Тары" :)

(43) Нет, этого мне не надо.
Если я сделаю "что не цену тары тебе нужно хранить, а сумму за всю тару + там же количество", то получится, как я определю сколько тары по конкретной цене? Буду составлять систему уравнений и решать? А если корней получится больше одного? Гадать на кофейной гуще?

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

(48) Использовать вместо "цены", дату продажи :)

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

(48)Т.е. предлагаешь хранить периодику изменения цены тары
А если в один день тара была отгружена по разной цене?
А если разным покупателям залоговая цена была изменена в разные дни?

И того мы (ты будешь) имеем, субконто:
1. Договор
2. Номенклатура (Тара)
3. Дата отгрузки тары

И Сумма там будет общая сумма на тару
И Количество, сколько штук тары... :)

(52) >>> А если в один день тара была отгружена по разной цене?

А это возможно? Ты узнай... странно, если так :)

+ >>> А если разным покупателям залоговая цена была изменена в разные дни?

И это уточни, такое может иметь место?
Порой бывает, что цена всегда одна и та же, ведь её нужно еще и помнить :)

(54), (55) Зачем уточнять? Такое было на практике. В основном из-за бардака, который описан в (26)

(53) Предлагаю не развивать этот вариант в этой ветке. Я его не приму.

(56) Ты не сможешь автоматизировать бардак :)
Исходи из идеального случая, все вовремя и цена меняется корректно :)

При том, какая в бане разница, по какой цене кому?
У тебя же там в первом субконто "Договор контрагента".
И Цена = Сумма / Количество... Для каждого клиента всегда своя цена

А дата тебе понадобится для списания мертвых "Тар" (душ)

(57) Как хочешь... я идеи подкидываю...
И сделал бы как в (53)... куда практичней...

Цена есть, Цена для каждого клиента ,Есть...
Можно списывать просроченную тару, если в договоре оговорен период возврата тары :)

Всегда будет известно, сколько еще у клиента осталось вашей тары, за которую он должен и по Сальдо будет известна дата, когда он отгружался :)

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

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

(57) это глупо.

(60) Ну... он к этому придет когда у него Сальдо разрастется, а у него спросят, как нам списывать :)

(62) ага. привезет покупатель сотню ведер  и закрывайте как хотите нам наплевать. Мы вам должны столько то тары на такую-то сумму.

(58) "Ты не сможешь автоматизировать бардак :)"
Почему же? Смогу, при этом получу "автоматизированный бардак". Дальше вступит в дело вторая скрипка (бухгалтер), которая этот бардак должна ликвидировать. Но меня это уже не касается. Мое дело будет уже сделано.

и вы покупателю никогда не докажите, что это ведро стоило столько то а это столько то одного типа.

Чтобы не иметь такой бардак с залоговой стоимостью тары, на нее назначают сумму заведомо большую себестоимости и +- за сколько ее закупили всем пофиг

(59) "Можно списывать просроченную тару" нельзя, для этого нужно знать дату отгрузки тары, которую вернули. Либо лепить ФИФО, который отношения к реальному учету не имеет никакого.

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

(60) т.е. если ему мы отгрузили одно ведро по 50 руб и два ведра по 60 руб. То когда он припрет взад 1 ведро, мы его примем по цене: (50+2*60)/3 = 56,6666667?
Представляю какие будут глаза у клиента и моего бухгалтера, когда я такое предложу.

Ладно, развлекайтесь дальше без меня. Для меня тема исчерпана.

(68) цену пишите какую хотите. главное конечный долг суммовой перед вами клиента.

ведро может стоить одно и тоже 50 и 60р? у вас никто ценообразованием не занимается?

Да. не оскудела земля российская глупостью

(68) Так и делайте партионный учет. А субконто "цена" - глупость.

(73) Он тебя не услышал... Ему и партионный учет излишен...
Хватило бы третьим субконто, документ отгрузки, коль нужно видеть точно до документа :)

(74) действительно. все просто.

как будто цена на субконто это не партионный учет. его еще и закрывать надо

Субконто цена естественно не глупость, и есть в типовых.

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

И навскидку можно придумать задачу где такое субконто либо измерение очень полезно - например... Залоговая тара.

(78) И как она, Оператор это делала, если перед ней только некое смутное список "Цена"?
И как она понимала, что именно 20.02.2013 она продала 30 коробок по 60 рублей, а вот уже 04.03.2013 по 80, но тоже 30 коробок....? Клиент попался всегда берущий по одной и той же партии поставки, но в разное время :)
...
Порядок твой вариант не принесет, но иллюзию создаст, до тех пор, пока клиент не захочет порвать с организацией :)

Либо по сути даже то, что ты пишешь "Субконто(3) - Цена" их тоже не волнует (им нужен список цен и количество по этой цене), так разве что бы клиента ткнуть, что вот вы брали по такой цене и такой, так что... тогда думается тебя устроит простое текстовое представление числа :)

(76) Это не партионный учет, это хуже.. Партионный учет подразумевает учет с точностью до партии товара, а цена в нескольких партиях может _внезапно_ совпасть, и получится не учет а непонятно что..

(81) Нормально это все. Вернее у (0), при учете коробок не важно, что вернул клиент, коробку за 80 или 60 р.
Важно сколько коробок и по какой цене за ним числится.
Проблема возникнет только при последней поставке. Но и это мелочи бизнеса :)

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

Единственное, что болит, это голова кладовщика. Когда он или она реально знает, что вернули и в каком состоянии :)

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

(83) Скажи это 1С. В типовой ТиС измерение регистра остаткиТМЦ - ЦенаПрод - Число. Для учета остатков товара в рознице в разрезе розничных цен.

И никаких глюков ни разу не наблюдал. Работает четко как часы.

Ситуация с возвратной тарой из той-же оперы.

(78) простите. но оператор принимает определенное кол-во и всетаки решает по какой цене ее принять. потому, что измерение надо закрывать! иначе итоги расползаются.

если за клиентом числиться 30 ведер по 50 и 20 по 60. Клиент привозит 60 ведер. Какие действия оператора.

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

(83) за давностью лет не помню точно где. но в рекомендациях 1с было не использовать в измерениях вид строку.

(84) посмотрел. действительно.

Вам еще не надоело?

(87) Думается от балды, какие захочет оператор. :)
Автор же сказал, что у них там бардак.
...
И какое настроение у оператора будет, так и закроет :)

(89) Нам любопытно, но я уже понял, как у вас ведется учет возвратной тары :)

(89) да все нормально. многие видят, как не надо делать то. что увас с тарой

(91) Почему-то я сомневаюсь.

(92) А как надо? Вести учет возврата в разрезе документов откгрузки?

(70) Ведро по 50 руб стоило в 2012 году, в 2013 - по 80.
Кто сказал, что цена тары со временем не изменяется?

Не стоит тара того, чтоб вести её учет в разрезе документов отгрузки. Водитель может забрать одномоментно тару с десятков отгрузок.

Мне интересно, как нужно вести учет тары с т.зр ЧеловекДуши и mishaPH.

Я знаю как сделать.
Создать Справочник.ДляСубконтоНетрадиционнойОриентации
Туда писать Формат(Число, "ЧПДС")

(98) Нафига справочник? Просто субконто число, и писать цену умноженную на 100 (в копейках)

(99) Так не интересно

Я сделал субконто строкой, в которое пишу: Формат(Цена,"Ч07.2")

(101) Гы. Я в (98) прикололся, а оказывается и взаправду так делают.

Короче, через строку нормально всё летает

Нет, через строку летит криво. Появляются лишние отборы одного и того же значения субконто. Причем на ровном месте ((

А если сделать строки фикс длины без пробелов? Добивай слева нулями - засунь ноль в формате в скобки.

(93) Не сомневайся, просто с твоим подходом написания алгоритма, другого учета не предусмотрено :)

(97) Вести так как вы ведете. Либо затратить кучу денег для соответствующего оборудования :)

(104) Как так? Ты же отбираешь не только по цене (строке).
Что там еще у тебя вылазить может?

(108) http://s1.ipicture.ru/uploads/20130312/fblF3E1o.jpg
Хотя движений по этому счету до 01.10.12 у меня ВООБЩЕ нет.
Он начальный остаток 0 раскладывает на составляющие +/- хотя никаких проводок для этого и в помине нет.

(105) Добиваю слева пробелами, но при записи в операцию движок эти пробелы режет.

Переделал субконто на справочник, как мне и советовали....

(110)
да это понятно. Разницу между нулем и пробелом не чувствуешь?
(111) оно и к лучшему...

(112) Разницу чувствую. Ну уж очень кривое получается тогда представление субконто.
Да ну нафик.
Пусть будет штатно - на справочниках. Заодно в справочник цен прикрутил контроль действия цены по периоду выписки документа.
Теперь при отгрузке тары по неактуальной цене - запрет проведения!
Нет худа без добра.