Что будет, если в регистре остатков будут минусовые остатки?
Например, реализовали S/N "58423983490", а прихода вообще не было
и таких отрицательных серийников много
что делать?
хелп!

из-за этого виснит конструкция
ВременныйРасчёт(1);
РассчитатьРегиструНа();
и открытие периода происходит 1,5 часа в ДБФ версии базы
а в скуле 1 минута всего

У тебя образуются отрицательные остатки на регистрах. Чем это грозит - решать тебе. И твоему ркуводству.

Денис2
см. 2е сообщение :-)

(3) Вы, Батенька, еще раз внимательно почитайте рекомендации товарищей + ЖКК на эту тему..

(0) сделай же что-нибудь... Чтоб такого не было.

так я и спрашиваю эти рекомендации :-)
дайте почитать, я не отказываюсь

Делайте приход раньше расхода
И почитай про последовательности, закрывайте период (дата запрета редактиирования)

(5) например, что?
удалить РГ и РА файлы?
и потом заново перепроводить все эти доки по этому регистру?
что открытие периода идёт под ДБФ 1,5 часа, что доки будут перепроводиться ещё дольше
не выход!
подскажите ещё варианты :-)
кроме того, что ставить SQL...

(7) последовательность не при чём
т.к. регистр самописный
и движения не касаются основной последовательности

что значит "Делайте приход раньше расхода"?
я спрашиваю как сейчас исправить эту ситуацию?
а не почему она сложилась
т.е. если действовать по вашим указаниям
нужно ловить минуосвые остатки по серийникам и заводить документ "Поступление серийных номеров" с проведением?
а "таких" минусовых порядка 5 тясяч записей
ничё так работка :-)
ценный совет! :-)
ЗЫ. По другому никак?

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

(11) т.е. сверни?
как в пункте 10?
или есть ещё варианты?
регистр остатков!
но менеджеры кривыми руками делают расход без прихода — это раз!
то что системники (системные блоки) имеют серийные номера и не имеют прихода в принципе, т.к. собираются из комплектухи — это два!
вот вам и минусы без прихода!
ЗЫ. я же спрашиваю совета как исправить, а не рассказать мне почему получилась такая ситуация! :-)

»

Как-как...
Если остатки нереальные - выдумывать приходы что ли?
Начни жизнь заново и введи нормальные остатки и живи по правилам

(12) а если нет прихода, то имхо, нужно делать "Комплектацию". Смотрел в типовой ТиС как там это реализовано?

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

Типичная проблема новичков: << я же спрашиваю совета как исправить, а не рассказать мне почему получилась такая ситуация!>> Перед тем как что-то исправлять, посмотреть, в чём причина. Именно причина. То что менеждеры "кривыми руками" списывали системники в минус, это по причине кривости твоих рук, потому что ты не предусмотрел контроль отрицательных остатков, это раз. То что ты не предусмотерл операцию комплектации и присваивание при этом серийных номеров, это два. Как исправить: перепроектировать всю конфу и переписать все модули. Грамотно.

(13) а о чем ты думал когда проектировал регистр?

(18) я проверял на скуль версии всё
потому что не было под БФ базы и речь не шал учёта под ДБФ
  
под скулем проблем не было тогда
и нет сейчас!
 
период открывается 30-40 секунд
 
а под ДБФ 1,5 часа (95 минут)
 
а учитывать миллион факторов на будущее не реально, потому что неизвестно что будет дальше
и ЭТО было требование директора
на складе есть вещь, но её не внесли в базу по серийникам
и что её нельзя продать?
или продать и не дать гарантийник?
 
это требование директора было
чтобы в любых подобных ситуациях можно было продавать
т.к. 30 человек-покупателей не будут ждать, когда менеджеры или на складе оформят сначала приход
 
они уйдут в другую фирму!
 
ещё раз повторяю, когда вводили речь про ДБФ базы не было
всё работало нормально под скулем!

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

(20) а я о чём? :-)
я знаю, что много незакрытых записей за год, т.е. по всем периодам
 
я спрашиваю сейчас как менее болезненно обнулить "минусы"
 
т.е. предложенный вариант должен быть предпочтительнее, чем поставить скуль на периферию!
 
повторяю, что в скуле нет такой проблемы вообще!
исходная база была оптимизирована под скуль
 
в ДБФ база занимает около 1,8ГГб
 
пока нашёл два не совсем правильных выхода
ждать открытие периода 1,5 часа на Целерон 1,8ГГц 256Мб памяти
(на пне4 3,2ГГц 1Гб памяти — 38 минут)
или
снести файлы RG и RA + CDX у этого регистра ДО открытия периода
тогда период даже под ДБФ открывается за 3-5 секунд
но тогда придётся перепроводить все доки по этому регистру заново!
что тоже долго очень
хотя уже всё оттестировано и работает :-(
но нужен "правильный" и менее трудоёмкий путь! :-)

<><>?‡‰Ќ?‡?„‰Њ‰…ШУЮЂЮЧЭУЭ‡Э։ЉЉЉ…ЮУЭ…ЮРЮ„ЮЧЮЂЮЦЮ…‰…ЮСЮЂ‰…Ю‡ЮР‰…Ю‡Э…ЮЂЮЦЮЂЮСЮЌ‰…ЮРЭ‡ЮФЭ…ЭЧЭ‡ЮЌЭУ‰…ЮУЮЂЭ…ЮЌЮРЮЃЮ…‰Р‰Р‰Р‰…ЮСЮ…‰…Э„Э†ЮУЮЂЭ…ЮФЮРЮЦЮУЮЂ‰…ЭСЭ‡ЮР‰…Ю‡ЮРЮРЮ„ЭЊЮЂ‰…Ю‚Ю…ЮЊЮЦЮЂЭ‡‰…Э„ЮЂЮФЭ†ЮСЮЃЭЧ‰…ЮЦЮРЮѓЮЂЭ‡?ЦЌ‡Њ‡?РШУЭ…ЮРЮ„ЮЧЮЂЮЦЮ…‰…ЮФЮРЭ…Э…ЮЂЮФЭ‡ЮСЮРЭ„Э‡ЮЌ‰…ЮЃЮ…ЮСЮСЭЧЭЂ‰…ЮЌ‰…Э…Ю…Ю‚Ю„Э†ЭЂЮ…ЮСЮЌЭУ‰…Ю„Ю…Ю‚ЭЧ‰…‰С‰…ЮСЮ…ЮФЭ†ЭУ‰…ЮСЭ†ЮѓЮЂЮС‰…Э‡Ю…ЮФЮРЮЊ‰…Э†Э‚ЮЂЭ‡‰…Ю‡ЮРЮРЮ„ЭЊЮЂ?У?ЦЌ‡Њ‡?РЯ‚ЮЌЭ‡Ю…ЮЊ‰…ЮУЭ…ЮЂЮѓЮСЮЌЮЂ‰…Э„ЮРЮ‡ЮЂЭ‡ЭЧ»µЯ

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

+22 с такими обьемами базы как-бы ты не извращался результат результат будет один ФИГНЯ, либо заводи новую с правильными начальными остатками либо иди на SQL

То 24. Если не закрывать регистры, то любая база через несколько месяцев будет несколько гигов. Болезнь (кривые руки автора) нужно лечить, а не снимать симптомы болезни (в виде размера базы).
То Новичок77. Не парь мозги в первую очередь себе, а затем присутствующим. Писать код нужно правильно. А не придумывать нелепые отмазки типа "под SQL работало, а под ВИА нет".

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

To 25 что понимать под закрытием регистра?

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

А как это связано с размерами базы

2(27) Особенность регистра остатков в том, что он стремиться закрыться (остатки, взаиморасчеты и т.п.)
Если все идет вразброд или несовпадают измерения - будет бо-бо

+29 в плане уменьшения её обьема

Если остатки закрываются - база (там где итоги лежат) не пухнеть (ну или размер этих таблиц колеблется)

(31) Не забыл что регистр остатков хранит остатки на начало Каждого своего периода? Вот и будет тянуться из месяца в месяц эта краснота плюс несрисанные комплектующие

То 29. Да напрямую. Регистр состоит из двух таблиц - таблицы движений и таблицы остатков. Таблица остатков содежит остатки на начало каждого периода (обычно месяц). При открытии периода вычисляется итог по старому периоду и формируется необходимое количество записей. Если итоги по старому периоду не закрыты, то каждое открытие периода добавляет в таблицу остатков записи.
Например:
1 января пришла корова рыжая одна. 2 января отдали корову пятнистую одну.
Остаток на 1 февраля - корова рыжая 1, корова пятнистая - 1.
Остаток на 1 марта - корова рыжая 1, корова пятнистая - 1.
И т.д. пока жива база.

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

Вариант 1 Красных остатков нет (ликвидировали движениями)
1. Таблица остатков будет меньше, но таблица движений больше.
Вариант 2 Красные остатки (приход не делали) что тогда?

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

Не совсем согласен
про таблицу движений забыл?
Но ради интереса в выходные померяю.

То 38. Внимательнее читай :))
Например имеем в январе одну кривую запись, соответствующую 1 строке в таблице движений и одной строке в таблице остатков.
1. В январе закрываем движение (+ 1 строка в таблице движений). Весь оставшийся год больше строк нет.
2. Не закрываем. В конце года в таблице движений 1 строка, в таблице остатков - 12 строк.
И не нужно ничего мерить - это базовые принципы работы с регистрами. Нет смысла самостоятельно убеждаться, что Земля круглая и покупать туристическую путевку на МКС. Можно поверить на слово или придти к такому выводу, применив логику.

Джинн, есть такая порода... все время надеются на чудо: "ведь так хочется!..." И ходят, уткнувшись носом в землю, червонцы отыскивая. И расшибая лоб о столбы...
:)

40 - болтун

То 41. Ты не прав в его отношении. Рекомендую всегда внимательно читать посты под этим ником. Многому научишься.

(41) Ну как, нашел способ не давать заходить в монопольный режим, не творя глупости клавиатурой в ГМ? Или считаешь себя крррутым программером?

42-не спорю, но все равно болтун.
43-там был способ как "не работать в монопольном режиме", ибо монопольный режим нужен для регламентных и внештатных операций, можно было понять.
я программер ? я же написал пират....

(44) Какой ты "пират"... Так...

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

Еще раз повторю: чтобы блокировать заход в монопольном режиме "не администратору", достаточно несколько взмахов мышкой. И только мышкой.
 
Учись...

хочу научитьс, как тогда дела с:
1. регламентными процедцрами -открытием периода ?
2. внештатными - переиндексацией ?

Читамем еще раз: способ как "не работать в монопольном режиме"
Все равно хочу "научиться", как тогда дела с:
1. регламентными процедцуами -открытием периода ?
2. внештатными - переиндексацией ?

Жаль, что пост 22 подчистили слегка :)
Мот автор и не успел прочитать
И где он, кстати? На какие действия созрел?

(48, 49) Нет уж, вьюношш, теперь сам...

А ведь знал, что имею дело с опытнм, старым политиком, забалтает по полной.
Я думаю Вам все же надо высказать свои секретные знания вслух, коль ветка обрела вторую тему. как сделать открытие периода и переиндексацию без разрешения на вход в монопольный режим.
P.S. Вход под Администратором не предлагать :) ибо тетюхам аптекарям это запоминать не надо.
P.S.S. все же жду именно ответ на заданный вопрос а не на комментарии.

2(39) однако задел
По пунктам
1 Согласен с тем что если остатки по измерениям 0 то размер таблицы остатков будет меньше
2 Утверждение о том что от отрицательных остатков база начинает пухнуть (37) по меньшей мере странное для 1С остатки что плюсовые что минусовые одно и тоже в плане размера базы.
3 "Закрывать" регистры в конце периода это уж совсем нонсенс. Во первых кто позволит, во вторых в начале периода вводить остатки? За что боролись на то и напоролись в плане размера.
  

Пожалуй последнее замечание к 39 применительно к теме вопроса в рассмотренном примере остаток минусовой резоный вопрос а что изменилось бы если он был бы плюсовым? Да полажуй ничего кроме того что автор не задал бы свой ворос а уж размер базы-то явно нестал бы меньше.
На счет кривых рук утверждение не мое но имеет место быть, а вот что учет веден неизвестно как это 100%.
Да и еще неужели у SQL и ДБФ версии столь столь порясающая разница, что-то не замечал, то ли автор темнит толи я чего не понял

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

(50) не прочитал, а что там было?
пока созрел до того, что выбрал все минусы по регистру и думаю сделать док "Поступление серийных номеров", т.е. закрыть минусы плюсами
1м документом, а не по каждому месяцу, т.к. база к тому же УРБД
там посмотрим к чему это приведёт
всё равно пока тестовую мучаю

для авторов, которые всё сетуют на кривые ручки
 
1) Где Вы такие умные были 6 месяцев назад, когда я тут спрашивал почему при выгрузки из скуль версии и дальнейшей загрузки в ДБФ не грузиться и тормозит как раз на пересчёте этого регистра
 
2) а Вы сами (каждый отдельно и все вместе) писали 2 года назад под платформу 7.7 с учётом выхода 8ки? :-) Нет? Да Вы что??? Выкиньте тогда все свои писульки нафиг, т.к. не учли будущего!
 
 
Для тех кто в танке: была задача, было время на решение, про УРБД и ДБФ базу стало ясно после 3х месяцев нормального использования уже сделанного. Проблемы всегда возникают именно, тогда, когда тех. задание меняют как перчатки — тут играем, тут не играем, а тут вообще рыбу заворачиваем :-)
 
Чтобы утешить чьё-то самолюбие: аттестата 1С:Специалист нет, т.е. не читал ОБЯЗАТЕЛЬНЫХ условий по выведению остатков в ноль и балы, которые за это снимают на аттестации
 
ЗЫ. Форму есть форум. Как всегда отдельное спасибо авторам, которые помогли советом и вникли в ситуацию, а остальные идите пейти пиво, для Вас тут ничего нового! Вы все сразу "авторами" родились :-)

57 - гонору дофига. ты просто смешон. хочешь чтобы тебе тут на форуме ЖКК цитировали?
Обратись к специалисту и иди учится.

(57) "тех. задание меняют как перчатки" - а вот здесь врешь, голуба. Такого не бывает. Процессы не прыгают, аки блохи. Это не техзадание было, это тебе объясняли как надо сделать, понимая видимо, что смысл тебе рассказывать бесполезно, и что проблему "как сделать" ты решить не в состоянии. А тот, кто подсказывал "как делать", в вопросах программирования ни бельмеса не смыслил сам.

2(57) Если бы я тебе отвечал полгода назад, то сказал бы, что регистр со множеством измерений или незакрытый - гимор при открытии периода и пересчете итогов
Согласен с (58)... хочется прямо добавить, да еще и этот ник забанят

То 53. "Положительный" остаток является необходимым. Собственно для его хранения и придуман регистр. "Отрицательный" остаток - это ненужный "мусор", который захламляет базу и не имеет никакой ценности. Неужели это так сложно понять?
Кроме того ГДЕ я писал, что нужно закрывать регистр в конце периода? Не нужно "творчески" перерабатывать мои высказывания. Закрытие регистра означает, что после ПОЛНОГО ЗАВЕРШЕНИЯ цикла остатки по ресурсов по всей комбинации измерений выйдут в ноль. Например купили товар - приход по регистру. Продали его - расход. Итогов в регистре по нему больше нет. И нет никакого "мусора".

2(61) Обожди... отрицательный тоже иногда нужен
Про остатки товаров - вопрос спорный, а про взаимроасчеты - достаточно удобно можно сделать (как в ТиС)

То 62. Замечу, что слова "положительный" и "отрицательный" специально были в кавычках :)

2(61) обьясню позицию:
Утверждение (25) в корне неверное также собственно как и (37)
отрицательные остатки как и остатки вообще в общий размер базы вносят минимальную лепту. Надеюсь расшифровывать не надо.
В остальном с (61) согласен.

61-64 , ребята, ну чего рассусоливать? В ЖКК все написано... правда однажды видел решение в котором ОСОЗНАННО регистр остатков не закрывался в 0. и по нему шли только приходы. Но это было оптимально для данной конкретной ситуации, хотя в итоге просто сделали внешние табличуи на SQL серваке...

(59) под тех. заданием понималось то, что нужно было сделать и где нужно было сделать... ещё раз повторюсь речь о ДБФ базе и УРБД вообще не шла
под скулем всё работало 3 месяца (без всяких проблем!) прежде, чем зашёл разговор об УРБД и ДБФ базе как периферии
 
а Вам как специалисту нужно решать последствия, а не говорить отчего это произошло! :-)
 
давайте я уволюсь и вас возьмут на моё место, но со словами "чем лечить такого ребёнка лучше сделать нового" вас выкинут зашкирку не успев оформить документы :-D
 
ИМХО, если кричите, что Вы офигенный специалист, то не говорите, что только ампутировать и ничто не поможет!

То 64. Ну вижу спорить с тобой бесполезно. Ты будешь смотреть на белый лист бумаги, и утверждать, что он черный.
По ходу подменяя суть вопроса и выкручиваясь для разнообразия. Например подменяя понятие "минусовые остатки" как несовпадение набора измерений при записи в регистр и при списании его понятием "итоги с отрицательным знаком". Которые вообще не имеют к контексту обсуждения никакого отношения.
Можешь верить 25, можешь не верить. Тем не менее закрытый регистр - прописная истина.
То 65. Если шли только приходы, т.е. накапливались обороты, а не остатки, то почему не следать его оборотным регистром?

66 - меня еще в "зашкирку" ни разу не выкидывали. :)
Это раз.
А два - это форум, а не бесплатные курсы для тех кому лень учится.
Если хотите помощи по таким вопросам, то заплатите денег и тогда все будет ОК.
По моему глубокому убеждению, самый лучший совет который можно дать в данной ситуации это - "читай ЖКК, уважаемый". Я на самом деле думаю, что это наилучший выход. А то был тут один товарищь, удалил таблицу 1sconst, а потом ругался что ему плохих советов надавали. :)

отталкиваясь от реальных данных поддержу (64)
под скулем период открывается чуть меньше минуты (Sempron 2200+ 256Mb)
под ДБФ 1,5 часа (Celeron 1800MHz 256Mb) и 39 минут на пень4 3,2ГГц и 1ГБ памяти
 
скуль центр, т.к. база УРБД объём в ДБФ варианте этой базы 1,5ГГб
ДБФ это периферия — объём базы 350Мб
 
данные в 4х файлах регистра по серийным номерам в 2 раза меньше аналогичных данных по регистру ПартииНаличие
и это с тем, что по 1му регистру "незакрытые периоды", т.е. минусовые остатки на каждый конец периода

То 69. Ты не врубишься в то, что тебе говорят. Какая разница, быстро-медленно? Какая разница, на чем ты запускаешь?
Ты написал кривой код. Это факт. И тебе рекомендуют учиться. Что само-по себе не является оскорблением.
Что ты начинаешь рогами упираться?

(68) в том то и дело, что это форум!
вы забываете о том, что в нормальных условиях здесь должно было быть решение выхода из этой ситуации моё или ещё чьё-то
 
а Вы превратили форум с вопросами в кадровое агентсво :-)
с рейтингом кто самый крутой
 
ЗЫ. Итог будет в том, что если я и найду решение, точнее оно найдено его осталось реализовать... ответа здесь небудет. И от этого пострадаете не Вы, а те кто столкнётся с такой ситуацией

я и не оправдываюсь, что мной были допущены ошибки
и что по сути нужно учиться
НО
(70) была поставлена реальная задача
а вместо советов, точнее на 2 дельных совета 30 мнений о том, что такая база не должна жить
и что нужно всё снести

2(67) В данном случае речь идет об итогах с отрицательным знаком читай внимательнее

То 71. Так тебе порекомендовали единственно правильное решение - переписать код таким образом, чтобы регистры закрывались. А заодно включить контроль остатков. Какой тебе совет нужен?
Типа "Читай на ночь Коран в течение 15 мин. и все само рассосется?"

71 - вы не горячитесь, иногда полезно почитать правила форума и следовать им.
Например не увидел пока номеров релизов 1С, версий операционок, версий SQL сервака, описания железа (желательно с сеткой) какая конфа и т.п.
А может для начала попробовать удаленную базу скопировать на сервак где лежит центральная перевести ее в СКЛ и посмотреть что выйдет?

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

То 73. Не передергивай :)
Все обсуждение крутилось вокруг незакрытых регистров, а не о знаке итогов.
Можешь еще раз все перечитать.

67 - короче там нужно было что-то типа периодически хреквизитов, но так как 1SCONST не резиновая, то решили сделать на регистрах. Но потом все-таки отказались и сделали на внешних таблицах.

(74)+(75) я спокоен!
но давайте смотреть на факты!
первоначально МНОЙ была сделана процедура контроля остатков по серийным номерам!
но "ЭТО" не подошло к реальной задаче
потому что реально менеджеры списывают те серийные номера, которые ещё не поступили, точнее на них не было сделано прихода!
потому что фирма компьютерная
1 из 10-15 в городе
и нельзя взять и сказать "не продавайте в минус хоть это быстро и не правильно"
потому что клиент уйдёт к другим
 
только поэтому "контроль" был удалён
моя ошибка в том, что я не увидел последствий заранее
НО
смягчающее обстоятельство ещё и то, что траблы только под ДБФ
а ДБФ ввели в строй через 3 месяца после успешной работы под скулем
и в то время про ДБФ вообще не было разговоров
(71) скажите как вам это поможет? :-)
025 платформа
ТиС 933 как под скулем так и под ДБФ
 
была сделана обратьная задача
выгрузка из скуля и загрузка в ДБФ
проблема найдена
 
делать наоборот, смысле нет, т.к. ДБФ (периферия) и следовательно она не может быть изменена на уровне конфигурации. Все изменения вносятся только в центре в конфу
и следовательно никто не мог нарушить структуру регистра на периферии

2(76) Это советовалось еще в (16) за расшифровку спасибо.
2(77) я не передергиваю см заголовок "прихода вообще не было"

2(76) Это советовалось еще в (16) за расшифровку спасибо.
2(77) я не передергиваю см заголовок "прихода вообще не было"

НЕЛЬЗЯ закрыть продажу в минусы!
НЕЛЬЗЯ!
Потому что менеджеры не будут смотреть остатки по регистру
и не будут звонить на склад и уточнять
был такой приход занесён в компьютер или не был
 
они реально смотрят на вещи
вот под рукой такая-то плашка памяти
вот у неё серийник
и им до батвы был по ней приход или не был!
им надо продать, чтобы клиент не стоял 30 минут и не ждал пока кто-то сделает приход, кто-то кого-то заменит на складе, потому что кто-то болеет, жениться или в больнице лежит...
 
вот вам реальная ситуация :-)
кто с этим не сталкивался пейте пиво!
а кто сталкивался тот поймёт, что нужно "затыкать" дыры
наименее ресурсоёмко
 
поставить скуль стоит денег, но это выход!

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

Автоматизация бардака...

кто читает между строк!
минусы это минусы по регистру серийные номера, а не количество!
 
т.е. реально пришло 20 резаков Нек 3520 с 20ю разными серийниками
по факту сделали приход по количеству, т.к. такой приход делается раньше
и не сделали по серийникам
а менеджеры продают уже со склада
и никто не будет ждать, когда разнесут эти 20 или 200 серийников
и никто не будет ждать у кого сломался сканер штрих-кода
клиента это всё извините не ё.............т
 
а 95% "советчиков" как я понял советуют закрыть фирму
и делать приходы
потом открыть и начать продавать, когда останется 0 клиентов
 
не сталкивались с ситуацией? и не надо тогда кричать про кривые руки
по правильному склад должен был сидеть и минусы тем же числом, но раньше по времени делать в приход,
но так как живём в России это оказалось нафиг никому не нужно и
пока всё работало...

То 82. В пятнадцатый раз объясняю - формат базы не имеет никакого значения.
Ну совершенно никакого. Что ты докопался до него, как пьяный к радио - сыграй да сыграй.
Если не можешь запретить продавать "в минус" (хоть я и не верю в принципиальную невозможность этого, особенно для компьютерной "комплектухи"), то все равно этот минус нужно потом ЗАКРЫВАТЬ приходом.

(83)
закрываются не просто отрицательные остатки!
а минусы после свёртки по всем измерениям регистра
т.е.
пример,
фирма+ТМЦ+Серийник+склад
сворачиваются в ТЗ
и получается, что минус превращается в ноль и пропускается, если был такой же плюс раньше
 
и обрабатываются только те минусы, которые после свёртки остались минусами
т.е. нет у них плюса
 
всё-таки, давайте не будем считать, что все такие глупые :-(

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

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

(89) ёпт!
ещё одна умница :-)
а принесут вам видюху по возврату
вы откуда возьмёте серийник по возврату и серийник по приходу?
из головы?
как Вы клиенту мотивируете, что это не ваша карточка, что её продала фирма "Рога и копыта" и никак не "ТД "Счастье"???
 
 
ЗЫ. Стало ясно буквально ВСЁ!
Кто не понял ситуацию тот и кричит про кривые руки — Вам бы такого счастья и флаг в руки!
 
А кто понял и даёт дельные советы — миллион раз спасибо!

(90) >> вы откуда возьмёте серийник
Только не из твоего регистра ...

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

(89) Точно
(87) Объясняю, то что у тебы продан серийник "ХХХ" в минус, также означает, что у тебя есть непроданный серийник "УУУ". Закроешь ты минусы, а плюсы у тебя остануться. И давай не будем путать, одно дело написать программу, и совсем другое - создать работающую систему с отрицательной обратной связью. В твоем случае, например, можно делать ежевечерний отчет по магазину, как только всплывает минус, то немедленно начать поиск причины - "не ввели"(кто и почему), "пересорт"(с чем), "ошибка при вводе"(исправить в нужном направлении), "принес из дома глюкнутую память и поменял на рабочую"(поменять менялу). Вот после того, как коллектив начнет работать в этом направлении, только тогда в базе будет порядок и босс получит нормальный учет.

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

Ты же в 56 сам ответил на свой вопрос, делай "Поступление серийных номеров", странно та что его у тебя до этого не было. Тем более ты ранее писал что номера серийников вбиваются в базу. Вопрос в какую же базу они вбиваются тогда, и каким оброзом, тут тоже не совсем понятно ?

(95) так ответов море, а нужен 1-2 наименее трудоёмких
точнее ресурсоёмких
время тоже в данном случае ресурс
1) можно ждать и 1,5 часа открытие периода
ушли менеджеры домой 31 августа оставили открытие периода на ночь
до утра откроется — тоже вариант, но сколько времени уходит?
2) снести 4 файла РГ + РА + индексы по этому регистру, тогда период открывается за 3 секунды, но потом перепроводить доки нужно будет
а это время... и не малое
3) по всем "минусам" внести плюсы
 
есть и другие неозвученные варианты
но нет 1-2 эффективных
пока остановился на варианте №3

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

(93) не означает!
потому что читать надо внимательно
прихода нет по минусам
а то, что в плюсе выбирается как остаток, т.е. его реально продать в любое время
т.е. при продаже возможны 2 случая
оформить документ "Реализация СН" путём ввести на осовании обычной ТиС реализации
и завести этот док без привязки к реализации
т.е. вручную
и тогда серийник можно выбрать не по остатку, который уже есть в базе, а просто считав серийник сканером штрих-кода
вот и мунус без плюса!
 
чё не догоняете никак?
 
"минусы" выловил по регистру
нет таких, когда поступил УУУ, а продали ХХХ!
все плюсы или есть реально на складе или их погасили минусами
т.е. нет левых приходов или висячих

(98) А вот это подробнее, плиз: "все плюсы или есть реально на складе или их погасили минусами"

ты уверен что это только из-за формата базы данных? А может дело в железе? или в каких-то настройках.

96) Да, но тогда минусы опять начнут копится в базе (по поводу варианта 3), до следующей "операции закрытиия минусов", что как то не красиво. Помоему стоит пересмотреть логику работы конфы, сносить под ноль ничего не нужно, но добавить что нибуть наверное стоит. Суть в том, что если есть телодвижение менеджера делоющие движения "-" ,должны быть телодвижения делающие "+". И такое телодвижение ны назвал, но оно почемуто не реализовано в конфе по сей день.

Надеюсь менеджеры не догадываются что в компе есть минусы, а то ведь и подзаработать можно - кто их знает сколько продали и неоприходовали на склад.
А как Ваша фирма называется?
Можно в гости зайти?

То 98. Ты явный претендент на главный приз по итогам года на проводимом здесь конкурсе :)
Если ты продал "в минус", считав серийник сканером, то тебе обязательно нужно оприходовать "в плюс" этот же товар с таким же серийником. Только тогда регистр закроется.

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

(104) Ага, и потом орг.мероприятия типа как в (93)?

Ветка обещает стать лидером :)
Жаль, что уходить скоро...

я так понял. что чел спрашивает про то почему в ДБФ версии итоги пересчитываются часами. а не про то как закрывать регистр.

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

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

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

народ начал оттягиваться :-)
2(98) Из тебя информацию клещами тянуть надо. В твоем вопросе уже есть ответ на все. Если товар УУУ продали и все ОК то почему такое случилось с ХХХ. Делай с ХХХ также как УУУ. Если это не возможно (например поставка в один офис а накл в другом, или большая партия посчитали по штукам, или кладовщику влом вбивать номера)тогда тебе самому придется придумать каким документов закрыть "-". Впрочем я так понимаю что и выдумать то ничего не надо раз с УУУ все ОК, просто посмори код.
Опять же если товар продали соответственно "-" повесили, то твой "+" должен вышать совсем не ты, а тот кто приходовал товар и соответсвенно решаться это должно административными мерами см посты выше. Если же хошечь сам то за каким чертом ты полез в 1С. На этом все итак разболтался :-)

(110) проблема в открытии периода под ДБФ
конкретно на Селерон 1,8 период открывается 1,5 часа
но при открытии периода база не в сетке
открытие периода происходит с той машины где конфа
трудно назвать это сервером
если сервером данной БД и то с натяжкой :-)
 
выяснил почему так долго
летит временый расчёт на этом регистре
т.е. конструкция типа
Рег.ВременныйРасчёт();
РассчитатьРегистрыНа()
 
при ТИИ, а конкретно при пересчёте итогов из конфигуратора
конфигуратор отваливается вообще без всяких ошибок!
закрылся и всё!
типа, а никто его и не запускал :-)
 
по словам директора поставить на периферию (там где ДБФ версия как раз)
пень4 3,2ГГц и 1Гиг памяти не выход
потому что 40 минут это всё равно долго
по сравнению с Селерон 1,8 и 256 памяти (1,5 часа)
 
вернуть контроль остатков по серийным номерам тоже нельзя
см. выше
даже если исправить сейчас + не ждать следующего открытия периода и опять ввести контроль на отрицательные остатки
т.е. я так понимаю придётся таким образом исправлять каждый месяц
я так понимаю для фирмы это дешевле, чем заставить складских искать минусы с помощью отчёта и вводить плюсы
 
менеджеры практически неприкасаемые
даже если они и косячат
получается со слов что они деньги зарабатывают на всю фирму

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

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

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

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

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

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

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

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

2(120) нет, учет у вас ведется впервую очередь именно по серийным номерам, именно серийным номером у вас идентифицируется одна единица товара. иначе бы у вас проблем сейчас никаких не было.

(119) это точно! :-)
только решение проблемы опять на мне
т.е. ясно было сказано по поводу фиг им, а не мощный компьютер, т.е. деньги тратить не хочется + скуль ставить тоже самое = денег стоит
 
единственное что могу сделать, это решить проблему 1 раз
и показать как это делается, а там перепоручить ещё кому-то
тому же складу
 
но думаю как кто-то заболеет и т.д.
то опять на меня повесят
 
с выгрузкой УРБД проходили уже
настроил всё, батник создал на рабочем столе
всё ок около месяца, как только начались отпуска
опять такая же ситуация
начались отговорки "я не помню" или "у меня винХП переставили" и т.д.
 
бардак блин :-(

120 Ну и кашу заварил!!! За каким дьяволом ты серийники тогда в регистр повесил, делай справочник и живи спокойно и не парь мозги себе и другим

(123) плюсы?
одни минусы через справочник...
начиная с получения остатков
и времени работы запроса
т.к. по справочнику не получишь ВыгрузитьИтоги()с установленными фильтрами
 
а минус с регистром пока один
глючит открытие периода и то ТОЛЬКО под ДБФ версией
система работает с октября 2004 года
где-то сначала 2005го база УРБД

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

То 124. На фига тебе остатки то? Ты и сейчас их не имеешь!
И вообще - я начинаю подозревать, что тебе нужно к врачу обратиться.
Сколько раз повторяли - ни при чем здесь DBF-SQL. Не, все равно та же песня!

1 Чиатать ЖКК на придмет регистров.
2 Читать ЖКК на преиет работы со справочником
3 Какие остатки???? (серийных номеров что-лиЭ, зачем они нужны вообще)

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

2(128) Дело вкуса, базу то сворачивают иногда.

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

(126)+(130) затем чтобы видеть есть остаток или нет
менеджеры же не всегда продают в минусы
стандатная ситуация, когда продают остаток, т.е. выбирают товар и в поле СН открывается список с СН по этому товару
т.е. выбирай любой
 
но бывает и так как описано выше
т.е. больше всё же "правильных" реализаций
 
что значит фраза "Сколько раз повторяли - ни при чем здесь DBF-SQL"?
на что не влияет?
т.е. то что я говорю, что под ДБФ период открывается 1,5 часа, а под скулем меньше минуты, Вы и это ставите под сомнение?
 
Поясните, что значит "ни при чём"?

анекдот в тему..
приходит ламер к программисту, приносит исходники, и спрашивает:
- А где у меня ошибка?
- в ДНК.

(131)
"затем чтобы видеть есть остаток или нет" но ведь инвентаризация по S/N не ведется и остаток S/N будет неверным ведь он ни кем не проверяется.
Если я правильно понял есть 2 Регистра остатков:
ОстаткиТМЦ - по нему проверяем кол-во товара (здесь как я понял все ок)
и ОстаткиСН - по нему частично минусовые остатки.
"поле СН открывается список с СН по этому товару" ну надо из этого списка менеджеру найти этот серийник, а если его нет то внести его вручную.
Ну и пусть этот серийныи хранится в самом документе реализации напротив ТМЦ.
И из него можно будет определить продавался ли он с таким S/N, а регистр ОстаткиСН снести.

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

(133) искать серийник по документу гораздо дольше, чем по регистру
гарантия 12 месяцев
а бывает и 3 года (мониторы и жёсткие диски и т.д.)
за 3 года реально нарыть тот док, который нужен?
или точнее сколько времени это займёт?
 
(134) правильно в этой ситуации не получится и это факт :-)
придётся дыркозатыкательством описаном выше...
 
ЗЫ. Тема закрыта! ИМХО: Можете дальше не комментировать...
читать время нет