Работаем без последовательности?

(96) Ничего не заболтали. Владимир пишет об частном решении частной задачи. Простой перенос решения на другую частную задачу ни к чему не приведет. Задача отказа от ТА, ГП и других квазинедостатках платформы не имеет общего решения в том виде, котором нас пытаюся убедить.

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

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

... и проведение "задним числом" будет подразумеваться как втискивание, рассталкивание "стопки" документов с учЁтом остатков на складе ...

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

... иначе "здесь" смотрим, "тут" перворачиваем, "там" потом скажу ... или забудет сказать мАленькое примечание ... или выясняется что у них аж несколько баз чтобы вести ОДИН учЁт - что уже само по себе НАСТОРАЖИВАЕТ ...

... и тогда бег по кругу ...

... вот ...

Остатки на складе учитывать на какой момент времени? На момент втискиваемого документа или на текущий момент (ТА)?

(100)
Да, "подмена тезиса", начиная с фразы "Обычно, под этим понимается проведение...". ;-)
В реальной жизни "ось времени" это не порядок укладки документов в стопки. А дата реальной, например, отгрузки товаров. И в базе данных документ должен иметь именно эту дату.
Я не преподношу ""заднее число" как наличие реквизита...". Это Вы так понимаете мои высказывания. Либо я плохо пишу, либо... Думаю, что причина такого разночтения возникает из-за того, что Вы пытаетесь привязать мои высказывания к понятиям "Оперативного учета" в определении от 1Са. Попробуйте на минутку забыть о том, что "Обычно, под этим понимается...". И ответить себе на вопрос - зачем, например, списывать нечто по "фифо" в момент проведения документов. Фиксируя тем самым порядок документов на искусственной "оси времени". Когда эти списания ни как не влияет на процесс торговли. И это всё можно посчитать в отчете...

(102) .. зачем НАМ гадать ...

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

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

... приношу извинения за этот оФФтоп и банальность мыслей ...

(103) ... бег по кругу ... бег по кругу ... бег по кругу ... уффф ... вот ...

(103)
Хм... В одинэсовой схеме документ имеет ту дату в базе данных которую имеет.
Но в твоей - это порядок укладки документов в стопки.
Что можно дальше обсуждать?

(106)
Да. Думаю, что обсуждать дальше не стоит. А то опять перейдем на обсуждение личности, как два года назад. Не понимаю как Вам удалось сделать вывод, что "Но в твоей - это порядок укладки документов в стопки". Я делал акцент на том, что не надо устанавливать "жесткую" зависимость между документами в момент их записи (проведения) в БД. Это же основы построения схемы базы данных - не хранить в базе данных информации, которую можно посчитать...

Допущения описаны в (46) и (54). Если они тебя устраивают - флаг тебе в руки.

З.Ы.
Утверждение, что проблема ТА и ГП решена, похожа на анекдот:
- Я, Джо-неуловимый!
- Поймать не могут?
- Нет, никто неловит!

(108) ... почему же ... откажитесь от "заднего числа" ...

... ихние "родные" программы даже не знают "красного сторно" а "заднее число" и вОООбще относят к загадочной русской душе ...


... механизм ТА и ГП это сигналы и как сигналы они и работают ... мы же уподобляемся Дон Кихотам ... вместо того чтобы "найти" удачное решение "заднего числа" - которое является естественным положением вещей для нас и ещЁ дОООлго, если не всегда, будет таковым являться ...


.. вот ...

(107)
Опа... А как же избыточность? Она позволяет сократить время выполнения расчетов за счет увеличения объема хранимых данных.
Важно, чтобы ресурсы, необходимые для поддержания избыточности, не превысили ресурсы, освобождаемые от ее наличия.

(108)
"Утверждение, что проблема ТА и ГП решена, похожа на анекдот"
Я никогда не утверждал, что эта проблема решена. Я утверждал, что от этих понятий надо отказаться для решения задачи в вопросе от Сергея. И об этом написал в (22) - самом начале данного обсуждения темы с моей стороны.
(101)
"или выясняется что у них аж несколько баз"
Дык, об этом написано в (62).

P.S. Александр ("Шёпот теней") и ......("poppy").
Мне всегда казалось, что вступая в разговор с другим человеком имеет смысл не только говорить (писать), но и слушать (читать) своего собеседника. Особенно, если вы высказываете не согласие с его позицией. Иначе это может показаться хамством с вашей стороны...

Хрен с ним. введем термин "оформление продажи задним числом". Стало проще? восстановить корректно документ, неверно занесенный ранее, чаще всего невозможно.Конечно, можно. Только вот без промежуточных расчетов нормальная база будет открывать документ минут 5-10 минимум.
Вариант "из-за невозможности корректно это сделать" не будем рассматривать?

Надо списать остатки товара, ГТД и может еще чего, если бизнес специфический. Как-то надо списать. Есть лучший вариант? Если не списывать, Вы будете продавать товар с одними и теми же характеристиками до потери пульса. Или будете хаотично руками выбирать те же ГТД-шки.
Зачем списывать сразу? Иногда надо видеть текущие фин.результаты. Иногда выстроить последовательность расчетов с поставщиками. Хоть как-то, но выстроить.
Да, на торговлю это не влияет, но на управление торговлей влияет.Про скорось такого подсчета уже писал.
Жесть.

(110)
"Важно, чтобы ресурсы, необходимые для поддержания избыточности, не превысили ресурсы, освобождаемые от ее наличия."
- Вы точно не читали всю тему. В целом вопрос именно так и ставится. Например в (87) со слов "поэтому ХОЧУ сделать инструмент".
А, на мой взгляд, выполнять монопольные или ресурсоёмкие пересчёты превышают "освобождаемые от ее наличия" (приведение её в правильное состояние) избыточности.

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

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

(112)
(113)
(Моха)
"Хрен с ним. введем термин "оформление продажи задним числом". Стало проще?"
- Дело не в термине. См. (86) и (89).
"восстановить корректно документ, неверно занесенный ранее, чаще всего невозможно"
- По каким причинам? Если - невозможно, то о чем тогда разговор? Работа идет приблизительно, что и "прописано" в сути "Оперативного учета" от 1Са.
"Конечно, можно. Только вот без промежуточных расчетов нормальная база будет открывать документ минут 5-10 минимум"
- Естественно, если перенести этот расчет из "проведения" в "открытие" документа. И это смысла не имеет. См. (88).
"Надо списать остатки товара, ГТД и может еще чего..."
- Списать остатки уже обсудили. Для ГТД организуем партии. Чего еще списываем?
"будете продавать товар с одними и теми же характеристиками до потери пульса"
- Партиями решается эта задача.
"Иногда надо видеть текущие фин.результаты."
- Именно - иногда. А документы проводятся всегда и всеми пользователями. Чего из этого требует большей скорости получения результат?
"Иногда выстроить последовательность расчетов с поставщиками. Хоть как-то, но выстроить."
- Я понимаю слово - "иногда". Но в моей практике не было случая, когда "хоть как-то" предпочиталось "точно", но спустя некоторое время.
"Про скорось такого подсчета уже писал."
- Скорость зависит от схемы БД и алгоритма отчета. Для ускорения данного процесса существует много способов. И, еще, важно чтобы числа в этой форме были верные, а не приблизительные из-за нарушенных последовательностей. А получение результата не требовало предварительного пере-проведения документов.
"Жесть."
- Ответ см. в (114).

А на фронт-энд и бэк-энд нравится?
оперативная база = база сегодняшнего дня. Вечерком заливают в учетную.

Например, весь товар с данной характеристикой продан по документам. Я уже писал об этом здесь.
Продать нельзя, согласен. Оформить можно?
Не передергивай. Остаток по-любому считать надо. Анализ продаж и т.п. будут блокировать всю работу.
Ты партии сначала спишешь, а потом рассчитаешь в конце м-ца, какие списал? Это как?
Эта задача решается партиями, если проводить по партиям СРАЗУ. Или предлагаешь остаток партий при проведении рассчитывать с начала деятельности?
Они проводятся ЗДЕСЬ и СЕЙЧАС, чтобы разбросать во времени суммарную нагрузку на расчеты.
В момей практике постоянно для фин.учета требуется примерно. Твое точно будет точным, если на складе отгружают именно то, что в накладной. Приведи пример, когда нужно это точно через Х часов/дней? Я докажу, что лучше примерно, но сейчас.Практика показывает иное. Все делают промежуточные расчеты.

+(119) Твое ТОЧНО = ТОЧНО по циферькам. А если брать суть, то это тоже +- лапоть. Только силы зря тратить.

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

(121) применяй. я не видел еще таких систем. только в мечтах отдельных юзеров.

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

(116) (Моха)
"пересчеты делают тогда, когда это можно,"
- Если положить нашу базу в штатную схему базы данных, то пере-счеты не смогут выполнится за приемлемые сроки. См. (24) про дату начала эксплуатации и (26) про "24х7". Свертку базы не обсуждаем. ;-)
"будут офигенные пики загруженности"
- Ответил в (117), предпоследний абзац.

(120) (Моха)
"Только силы зря тратить"
Это самый сильный аргумент с Вашей стороны в нашей беседе. Надо было с него начинать разговор. Я бы столько времени с-экономил ;-)))

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

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

(122)
Уже применили. Работает с 2001 года. Я же во всех своих сообщениях пишу слово "работает", а не "будет работать". ;-)

(123)
Я это понимаю. И, по жизни, проходил через это. Еще и переделку системы в таких условиях делать сложно. Не знаю какой из этого выход. :-(

(127)
Я применяю слова "не могу понять" в смысле "не могу принять". А с разделением понятий "оформить", "продать" я сталкиваюсь с 1974 года - как только попал в АСУп. И когда появилась выражение: "Я не просто ... сосу, а работаю в АСУ".

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

(131)
Если у Вас это так, то не надо тратить своё время на разговоры в этой теме форума. У Вас отличная (хорошая, правильная и т.д) система...

Идея Пети никак не дойдет до умов. Главный Дятловод долго писал про то как это решить, видимо Че пропустил эту ветку :)
Ну а если тупо расчитать приход-расход за период от документа до ТА и просмотреть движения на возможность отрицательных остатков?

(132) Я просто не верю в чудеса. Весь мир работает на сохранении рассчетных итогов в таблицах и еле-еле пыхтит. Нереально такое удерживать в тайне 30 лет. Пересчет на лету возможет только в исключительно узких случаях. К сожалению, наше законодательство не оставляет нами сейчас таких возможностей. Уберите ГТД и эти возможности сразу появятся. А пока ... пока.
(133) Пересчитать в момент оформления документа? Это несколько неудобно, чтобы быть массовой операцией.

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

(135) Даже текущим днем не все делается оперативно. Иначе поступления будут после реализаций.
В противном случае, кстати, зачем ради разовой операции городить огород? Лучше сделать консольку продвинутому пользователю.

(133) в том-то и дело... что ветки с описанием решения у Петра я не видел (пропустил?), или Петр прав и 1сники (я) - тупые, не видим очевидного... А поискать ту ветку или хотя бы натолкнуть на путь истинный (в личке?)

(135)
- по сути это мало чем будет отличаться от восстановления последовательности...

(137) И не только 1С-ники. Такой учет партий отсутствует и в других системах.

(136) Отборы уже отменили? Попробуй сделать стандартный отчет с отбором по товару и складу. Не так страшен чёрт, как ГП.
(137) Был разбор полетов. Петр там отметился, а после возникновения этого решения срулил и больше на мисте не появляется.
(138) Ну ведь надо просмотреть только измененные позиции.
(139) Про партии я не говорю, это другая песня.

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

Взял на себя труд выписать «слова» Владимира и обобщить …

Представлена некая система, назовём её: «Торговый учёт».

Имеется в виду только учёт склад-магазин. Бухгалтерский учёт отделён. Данные в бухгалтерский учёт переносятся выгрузкой.

Система хранит Общий Итог.
Проведение документов осуществляется самостоятельно. Приход увеличивает ОИ, расход, соответственно уменьшает ОИ.
Не стоит этот абзац рассматривать как издевательство - это попытка показать что именно тут демонстрируется принципиально новый подход в организации учёта. Читаем дальше ...

Далее выдержки автора, расшифровывающие систему и мною сокращённые:

Разработали свою систему "регистров" на справочниках.
Для этого достаточно одной таблицы БД. Мы отказались от понятий 1Са: расположение документов на оси времени, точка актуальности, последовательности документов, итоги на..., перенос итогов, закрытие/открытие периода, регистры и т.д. Т.е. мы отказались от всех "фундаментальных" понятий "Оперативного учета".

Дополнительные частности системы:

1- Документы проводятся (записываются в базу) собственной датой документа.

2- Проведенный документ можно изменить, перепровести, снять с проведения.
2-1- Отмена осуществляется кнопкой "Отмена проведения". Но если, при отмене, проведения документа возникают условия отрицательных остатков, то де-проведение не выполнится.
2-1- Исправление документа делается путем открытия документа и непосредственным его редактированием с последующим проведением.

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

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

7- старые значения остатков получаются так, как описано в пункте #5. И делается это так исходя из того, что старое значение остатков требуется редко и не мгновенно.

8- В документе есть даты, кроме даты проведения документа. Т.к. некоторые виды документов не "описываются" одной датой. См. пункт #1. И никаким образом эти даты не связаны (не имеют отношения) с/к "задним числом" в контексте темы данного форума.

Основные дополнения к системе в целом:

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

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

Добавление3.
Надо отказаться от списания по "фифо" и других "сПисаний" в момент проведения документов. Повторю. Не надо делать в момент проведения документа никаких действий с данными, которые не требуются в данный момент и/или устанавливают "жесткую" зависимость от других документов. Т.е. документ должен своим проведением "регистрировать" в базе только СВОИ данные. А все остальное делается отчетами...

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


Мои выводы:

Имеем классическую ТРЁХоконную систему: Приход-Расход-Остаток.

Идею ТРЁХоконной системы разработал Федор Венедиктович Езерский (1836 - 1916). Рекомендую почитать. Она всё чаще и чаще попадается в том или ином виде.

Документ – самостоятельная единица. Сам делает движения. Взаимосвязь документов исключена (именно в этом заключается понятие – самостоятельная единица).

Каждая строка документа – является самостоятельной единицей записи (нет лифо, фифо - именно в этом заключается понятие – самостоятельная единица).

Основная система регистров (учёт данных) – реализована на справочниках.

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

Минимизировано количество хранимых данных минимально. Всё что можно посчитать вычисляется, а не хранится.

В целом с «Владимиром» я полностью согласен. Для меня остаётся не выясненный вопрос: где и как хранятся цены, связаны ли они с конкретной номенклатурой и т.д. Где и как считается себестоимость.

… вОООт …

п.с.1. проще было всё таки описать автору ВСЮ систему самому ...
п.с.2. выложить демонстрационную конфигурацию ...
п.с.3. всЁ таки многим интересно и "одна" голова хорошо а "ИС" лучше ...

...

... Владимир - продемонстрировал яркий и добрый пример как не нужно замыкаться в отдельно взятой 1С ... её универсальность и глобальность имеет свои "плюсы" и "минусы" ...

... с Уважением Шёпот теней ...

дополнительно хотелось бы знать:
1. документооборот в год: количество, строк в документе
2. количественно - суммовой оборот в год
3. размер информационной базы за год
4. ... любые другие статистические данные ...
(например, количественно-суммовое расхождение выявленное при инвентаризации и т.д.) ...

...

я ща к новому году буду примерно такую же систему "толкать". ГТД - отвязано от Партий (самостоятельный учет). Партионный учет - нафиг не нужен. В торговой системе - только оперативная работа. все расчеты списаний/партий/фифо/лифо - в бухии после выгрузки.
.
Непонтно, почему ряд вопросов (не до конца понятных) был реализован на справочниках, а не на регистрах?

... много чего НЕпонятного есть у "Владимир"а ... он же молчит как партизан ...

... надюсь, Вы господин ЧЕ не будете таким же "жадными" и поделитесь статьями и демонстрационными базами ... ?

... вот ...

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

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

... вот ...

плохо то, что в типовых - толком ничего нельзя сделать на доках - я вот вынужден все по работе со сканерами писать в спр., потому что блин общий журнал документов блокируется!!! поубивал бы гада кто так систему планирует, где основное - ДОКУМЕНТЫ! уроды...

(143)
Сергей.
По Вашему сообщению мне видится не полная передача (прием) информации по теме. Например, без "партий" (условный термин) это ВСЁ никак не реализуется. Т.к. "...наше законодательство не оставляет нами сейчас таких возможностей."(с) из (134). Т.е. ГТД это пример искусственного, обязательного "жесткого" связывания уже не производной информации, а непосредственно "документов" (назовем это привычным термином - "документ").

(142)
Александр, спасибо...
На некоторые вопросы из завершения Вашего сообщения я не могу ответить. Причины - разные ;-). Пока дам общую характеристику предприятия:
1) Внедрение системы в 2001 году.
2) Первичная разработка около трех-четырех месяцев. Термин - "первичная" т.к. система меняется, развивается, наращивается и т.д. по сей день.
3) Разработчики и эксплуататоры все в штате фирмы.
4) Предприятие занимается торговлей и ремонтом.
5) Торговля оптовая и розничная.
6) Подразделения охвачены нашей разработкой (кто пользуется системой и сидит в общей базе): бухгалтерия, склад, торговый (розничный) зал, оптовый отдел продаж, менеджеры закупки, приемка, ремонтники, проходная, кафе, автостоянка, руководство, администраторы системы.
7) Номенклатура торговли - около 60000 наименований.
8) Простенькие партии в лице номерных изделий.
9) Виды работ, норм, тарифов и прочей - сотни тысяч. Точно сказать не могу, т.к. сложная (хитрая) схема БД и перевести это к "подсчитываемым" (аналогично номенклатуры) единицам очень трудно. А писать программу для их подсчета - очень лень.
10) Количество ККМ менялось за это время. Сейчас - 10 штук.
11) Количество строк в документах очень разное. Особенно если учесть, что чеки преобразуются в документ "Отчет кассовых смен" по окончанию смены. Но, по моим замерам в часы пик чеки ложатся в базу - одна штука каждые пять секунд.
12) Размер базы (в DBF-ных единицах измерения) - 9 гигабайт.
13) Система работает в режиме 24х7 благодаря отказу от монопольных работ (в понятии 1Са) и "распределенной системе БД" собственной разработки. На данный момент функционирует 3-5 синхронных (одинаковых) БД. Синхронизация баз "по объектная" в автоматическом режиме. При отказе сервера пользователи в ручном режиме переводятся на другой сервер. Потеря данных, при этом - "только то, что на экране пользователя".
14) Количество пользователей в системе около 50. При этом в центральной базе около 40 пользователей одновременно (в часы пик).

"где и как хранятся цены, связаны ли они с конкретной номенклатурой"
В штатном ЯМД "1С 7.7" мало средств для определения и работы с "нормальными" структурами данных. Поэтому цены хранятся в "подчинении" отдельным справочником. Я расширил ЯМД в своих разработках "DBEng32 для ...". Но работы по переходу на другие схемы БД идут очень медленно по многим причинам. Одна из которых - "и так всё хорошо работает". ;-)
Описание файла цен:
Ключ (ТипУч+Категория+Фирма+Объект)
Цена (периодический реквизит).
,где:
Категория - грубо говоря любое значение "природы" цены. У нас 0-приходная, 1-расходная. Можно назначать любой значение. Например, мелкий-опт, крупный-опт и т.д. для разлчной политики цен. Это закладывалось под развитие системы в части прайс-листов.
Объект - ссылка на элемент любого справочник. Сейчас ссылается либо на элемент номенклатуры, либо на элемент справочника "партии".
Остальные поля ключа понятны и без расшифровки ;-)

(144)
"много чего НЕпонятного есть у "Владимир"а ... он же молчит как партизан"
Спрашивайте, отвечу. Я не "партизан". Просто мне так надоело и приелось это АСУп, что очень сложно излагать очевидные (для меня) вещи. Я не имею дара "писателя для широкой аудитории". Но поговорит могу с удовольствием... ;-)

(146) по (143)
> Например, без "партий" (условный термин) это ВСЁ никак не реализуется.
- почему? тут вполне обычный учет остатков в разрезе ГТД - можно это считать упрощенно йпартией - учет ГТД все достаточно просто, так как вообщем нет нигде обоснований вести учет ГТД в "разрезе" стоимости - соответсвенно это существенно упрощает учет ГТД...

(147)
Естественно - так. Я "партией" называю еще один уровень справочника номенклатуры (подчиненный справочник в терминах 1Са). Со своими остатками. Все остальные решения это ИХ понимание "партии"... ;-)

(+146) по (142)
"Где и как считается себестоимость"
Считается (используется) в нашей базе, отчетами. И результат передаётся в бухгалтерию. Отчеты писал наш "младший научный сотрудник" на моих "функционалах" доступа к БД. И наш начальник не подпускал меня к этой задаче. Берег мои нервы... ;-)

Владимир ... и всЁ таки ... ситуация ...

новый приход ... как ? записывается приходящая номенклатура в спр.Номенклатура:

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

или

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

.. вот ...

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

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

Могу даже сказать, кому такая схема не подойдет: некрупным компаниям, которые по какой-либо причине вынуждены контролировать прибыль от каждого болта. Как правило, у них или достаточно молодые, или флуктуирующие схемы работы.
Корень зла - ценообразование, ИМХО.

(150)
"новый приход ... как"
Структура справочника "цен" из (146) это СПРАВОЧНИК цен. Т.е. в момент набивки приходной накладной оператор получает информацию о цене прошлого прихода (для "посмотреть") и записывается в это справочник свежая приходная цена. И формируется цена продажи (для "выбрать") в расходных операциях. А собственно цена прихода и продажи хранится в той самой единственной таблице движения. Суть всей торговли (условно говоря!!!) это продал/купил:
Кому
Кто
Чего
Когда
Сколько (если нет привода к базовым единицам, то надо еще хранить "единицу измерения")
НаСумму (если разная валюта, то надо еще хранить "единицу измерения" валюты)
ДопУсловия (в простейшем случае ссылка на документ)
Всё остальное это удобства пользователя, отчеты для налоговой, анализ прибыли и т.д.

(152)
"из-за ГТД-шек возможны неисправимые ошибки"
Неисправимые - где?
1) База данных (программная система).
2) Печатная форма документа (с реальными печатями и подписями).
3) Отчет проверяющим органам (сданный баланс).
4) Любопытные глазки нашего (родного) бухгалтера.
Для каждого места - свой способ исправления ошибки. Моя "жизнь в АСУп-е" показывает, что такие ошибки ВСЕГДА исправляются с разным уровнем автоматизации процесса исправления ошибки и без воздействия (нарушения) на процесс торговли. Надо, думаю, автоматизировать торговлю ТОВАРАМИ, а не НДС-ами, ГСМ-ами и т.д.
А "заднее число" в торговле есть всегда. Т.к. существует необходимость готовить документы на отгрузку товаров на следующее число и передавать информацию в реальный склад для подготовки реальных "контейнеров" развоза товаров. А еще и надо продавать сегодня. И не допускать ситуации, когда грузчикам или клиентам объявляют о отсутствии товара на полках после оформления пакета документов...
(153)
"такая схема не подойдет: некрупным компаниям, которые по какой-либо причине вынуждены контролировать прибыль от каждого болта."
У нас НЕ крупная компания. Мы контролируем прибыль "от каждого болта". Речь, с моей стороны идет, не о приблизительных расчетах прибыли, а о том когда и где (в программной системе) это делать. И не ставить основной задачей - например, посмотреть прибыль сразу после продажи "каждого болта". Ну а если и посмотреть, то не в торговом зале на рабочем месте продавца, а в кабинете директора (бухгалтера) другими программными средствами (отчетами). Но в общей базе данных!!! И если эти пользователи не хотят долго ждать, то оптимизировать (ускорять) их средства работы с базой данных (отчеты). Но не путем замедления работы и проблем в торговом зале...

Так и хочется ответить в рифму. Представляете, что из-за неправельно введенного документа в базу продали по ГТД больше, чем можноСтыдно должно Вам быть за эту фразу. Посмотрите хотя бы на ТОРГ-12. Там есть вверху дата выписки, а внизу дата получения. И никакого заднего числа в идеале быть тут не может. Заднее число здесь от желания отдельных личностей отгрузку и получение товара оформить в один день.
Владимир, я НИЗАЧТО НИКОГДА не поверю, что отчеты можно заоптимизировать так, что они будут быстро давать результаты без промежуточно вычисленных данных. В типовых 1С масса вариантов как непосредственных так и отложенных таких расчетов. В конце концов в той же УТ Вы можете не делать движения в момент проведения документов. Можете потом скопом их сделать в конце периода, а можете вообще не делать. Но не очень подходит Ваш вариант в случаях импортного товара.

(+154) по (153)
"Корень зла - ценообразование"
Никаким образом ценообразование не влияет на "корень зла". Ценообразование это отдельная (не от базы данных!!!) задача (подсистема) - "прайс-лист". Например, в прошлой моей системе было 3000 оптовых клиентов и 50 видов прайс-листов. И в каждом по пять колонок "политик" цен. Ни на учет в бухгалтерии, ни на "узнавание прибыли", ни на скорость работы менеджеров продаж и т.д. это не влияло и решения проблемы типа "восстановления последовательности" не требовало.

Поддержу (156) - ценообразование на скорость работы влияет ну очень мало...

(156)Расшифровываю. Если Вы формируете прайс рефлексируя на цену прихода, Вы обречены на проблемы вести жесткую партионку. В противном случае у Вас развязаны руки.

(157)Седня конкретно влияло сильно.

(154) ... не удовлетворЁн ответом на (150) - поэтому повторюсь с дополнением :

1.новый приход ... как ? записывается приходящая номенклатура в спр.Номенклатура:

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

2. справочник номенклатура - какова его структура т.е. сколько у него аналитических признаков (грубо говоря колонок)

... есть ли у него подчинЁнные справочники и сколько и как называются и и какова их структура (аналитические признаки - колонки) ...

... вот ...

(158) расшифровываю: наличие в прайсах одной номенклатуры с разными продажными ценами - это имеет смысл только в штучных изделиях, или в условиях жестокого колбасения рынка (курса доллара?). при наличии на складе ПО УЧЕТУ нескольких партий пр разной себестоимости - никто не будет плювать в прайс несколько продажных цен на одну номенклатуру... - так что - ПО_СРЕДНЕМУ ;-)! весь "партионный учет для целей прайса". или еще проще: И ТАК ДЕЛАЮТ ОЧЕНЬ МНОГИЕ: цена в прайсе выставляется "от себестоимости" ПОСЛЕДНЕЙ ПАРТИИ ПРИХОДА - а так как цены у нас НУ ОЧЕНЬ РЕДКО ПАДАЮ - то все понятно... ;-)

(161) В минус не боишься продать?

(162) неа, не боюсь... потому что автоматическая ценовая политика (рассчитываемая/устанавливаемая программно - то есть лично мной написанный алгоритм) - В ОБЩЕЙ МАССЕ будет считать ЛУЧШЕ ЧЕМ ЛЮБОЙ ЗАКУПЩИК/ПРОДАЖНИК. который РУЧКАМИ/ВИЗУАЛЬНО/ИЛИ ЕЩЕ КАК в принуипе не сможет ПРОКОНТРОЛИРОВАТЬ правильность/обоснованность расчета 2000 - 3000 позиций, да еще по куче прайсов. Пусть закупщик обозначит мне десяток-другой-третий позиций которые он берет под свой контроль (дефициты, крупные разовые партии итд). В итоге: выигрыш от "моей" ценовой политики будет больше, чем от закупщика, который хочет большую зарплату, а при этом убивает кучу времени на несколько контролируемых позиций - а все остальное - по приницпу "ну тут нормально будет" - поверь, как и Владимир, я работал по десятку прайсов от 300 до 10 тыс позиций (лекарства) где цена на рынке менялась каждый день - и кучу раз (я задалбывался объяснять "продвинутому персоналу") мои алгоритмические оценки были обоснованнее всяких "ноухавов" из головы супер-пупер специалистов... ;-)

(163) Хм. в фармации посерийный учет. Не очень понимаю, что за принципы ценообразования у тя и как они сопрягаются с "правильным" маркетингом?

Я работал в фармации. Аптека = от 5000 наименований обычно. Тупо цена устанавливалась на новую серии, как только кончалась старая. С учетом максимальных разрешенных наценок.

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

по законам АБЦ и ЧНЯ человек должен контролировать от 10 до 20 % продаваемой номенклатуры ...

... даже от 3 000 позиций это будет приблизительно 500 позиций ... реальность ещё меньше ... по поводу остальной номенклатуры можно почти и не беспокоиться - в одном месяце "+" в другом пол"+"...
... кстати, преднамеренная "минусовая" торговля на незначашей номенклатуре есть рекламная компания под именем "у нас самые дешЁвые цены" ...

... в каждых продажах есть номенклатуры, их штук 10...20 - точкиКонтроля - контролируя которые вы можете рассказать почти всё о состоянии торговли вчера-сегодня-завтра ...

... вот такое есть мнение ...

(155)
"Представляете, что из-за неправельно введенного документа в базу продали по ГТД больше, чем можно"
Не представляю. ;-) Уже по N-ому кругу пошли. Если в Вашей системе нет необходимости вести точный "количественный учет на ГТД", то и хрен с ним. Если требуется вести, то такое невозможно. Т.к. на ГТД ведутся остатки с запрещением появления минуса...
"Стыдно должно Вам быть за эту фразу"
Плохая Ваша фраза (про стыд). :-((( Не конструктивная.
"Посмотрите хотя бы на ТОРГ-12."
А причем здесь ТОРГ-12. Посмотрите "хотя бы" сообщение (142) от Александра (еще раз ему - спасибо!), если не хочется разбираться в отдельных моих "писульках".
....
....
....
А можно, я дальше не буду Вам отвечать?
У нас с Вами получается как "про велосипед и спицы" из (93).
Давайте побережем Ваше и мое время.
Ага? ;-)

Так представьте же наконец!!! У Вас, что, ГТД на коробках написаны, что Вы их поштучно не в компьютере можете контролировать!!! Я ж пример приводил в этой ветке!!!

2Владимир
Конечно можно не отвечать. Я Вам про то, что можно списать все товары по ГТД №1. Потом найти ошибку оператора задним числом, а исправить ее уже не удастся, т.к. в документе, полученном и увезенном в Бобруйск-на-Дону контрагентом, проставлена вполне конкретная ГТД №1. Это непонятно?

ТОРГ12 тут при том, что попытка притянуть заднее/переднее число как необходимость учета не засчитана! правила выписки документов не требуют выписывать их в день отгрузки.

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

И что это за секретные оптимизированные до опупения мегауправленческие отчеты, которые на порядок быстрее штатных 1С-ных работают даже без промежуточно собранных данных.

... жаль, что тАААк и не удалось получить ответ на (160) ... вОООт ...

(160)
"новый приход ... как ? записывается приходящая номенклатура в спр.Номенклатура:
новым элементом справочника или прибавляется к аналогичной - тогда понятно, что такое цена ...или прибавляется к аналогичной - тогда цена хранится как ? в разрезе каждого прихода или валом ... "
Если товар новый, то вносится элемент в справочник "Номенклатура" (описание товара).
Цена поставщика вносится в справочник цен (связанный с номенклатурой).
Вычисляется цена продажи по алгоритмам стратегии цен продаж.
Цена продажи вносится в справочник цен.
Обе цены - отдельный записи в таблице цен с разными признаками и одинаковой датой. Т.е. если отбросить методику хранения средствами 1Са, то вид этой таблицы такой:
СылкаНаТовар ВидЦены ДатаПоявления ЗначениеЦены
Но этот справочник используется ТОЛЬКО для обеспечения выбора цены при продаже (в диалоге) - подготовки расходных документов. Все вычисления с ценами выполняются с данными из таблицы (та, которая единственная - почти регистры). В этой таблице, в частности хранится эквивалент строки приходного документа. Там есть дата прихода, количество, сумма.

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

"... есть ли у него подчинЁнные справочники и сколько и как называются и и какова их структура (аналитические признаки - колонки) ..."
Не все подчиненные справочники "подчиненные" (в терминах 1С). Т.е. подчинение организуется ссылкой на элемент справочника товаров.
1) Цены.
2) Партии/Номерные товары.
3) Флаги управления оперативной подачи товара в розничный зал и генерации запроса менеджеру закупки на дополнительное приобретение товаров. Т.е. узко-спец. применение.
Вроде, и - всё. Остальное это ссылки на элемент в чистом виде... Из документов, наших "регистров" и т.д.

(161)
Сергей.
Разный опыт, разные специфики...
Но общее и главное в текущем вопросе.
Да. В прайс никто (в здравом уме) не будет ставить цены в зависимости от закупочных цен. В моём случае это делалось не из-за закупочных цен. Кстати, я, вроде ошибся (перепутал) - клиентов было - 2000, а товаров - 3000. Но это не важно, по значению. Важно соотношение - примерно 50*5 значений цен. А еще в некоторые прайс-лист не включались некоторые товары для некоторых покупателей. Т.е. всё с отпускными ценами сложно и запутанно. Но два момента. Первый. Обеспечить быструю работы менеджера продаж. В той системе он вообще не смотрел в бумажки. Цена ему "выскакивала" автоматически. Второй момент. Что для расчета прибыли и всего прочего (о чем мы говорим) это многообразие цен никаким боком не ... В базу пишется цена набитая менеджером в строке документа. И никакой связи с закупочными ценами "в реальном масштабе времени" не существует.

(169)
"Так представьте же наконец!!!"
Блин. Это Вы представьте. Что ГТД это то-же самое, что товар. По неё ведётся учет остатков. И перечитайте всю эту тему заменив слово "товар" на "ГТД". Мы там выше бодались по поводу продажи задним числом товара. Теперь будем бодаться тем же местом по поводу ГТД...

(169)
"По мне Вы автоматизируете/автоматизировали что-то живущее своей отдельной жизнью от бухучета."
Блин!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Ну наконец.
Я это написал в самом начале своего вступления в тему.
Я автоматизирую и автоматизировал ТОРГОВЛЮ (сам процесс).
И обеспечиваю бухгалтерии не противоречивые данные для УЧЕТА.
И эта система не требую дубляжа прихода, расхода, оплаты, возврата и т.д. в двух системах.

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

(166) и это требование никто не выполняет. это раз ;-)
два: аптеки не держат СКЛАДСКИХ запасов. и поэтому вопросы ценообразования у них - достаточно просты. А то что a фармации посерийный учет - это ваще никаким боком. в типовой ТиС - пофирменный.. какая на разница - будет еще посерийный...

Моха, еще раз: нет нигде требований по количественному учету ГТД. - это "ребенок" 1С. второе: в отпускных документах неоюходимо указывать ГТД ___в соответствии документам поставщика: "указанными в счф И товаросопроводительных документах" - еще раз обращаю внимание на союз И. если у отгрузочных документах ты указал ГТД ТОЛЬКО В СООТВЕТСТВИИ СО СЧФ поставщика - ты уже нарушил требование НК. потому что не выполнено существенное условие по соответствию "И товароспроводительных документов". так что при невыполнении этого условия количественный учет ГТД - все равно будет неверным - не в соответстсвии... За всю мою историю только сеть "real, -гипермаркет" требует от поставщика указания ГТД в счф и товароспопроводитеьном документе (торг12)

(179) В 8-ке учет по ГТД отключается на раз. Если не паримся по этому поводу, то вообще какие у вас трудности? Ты просто смело продаешь товар, пока он у тебя есть, подставляя накладные да хоть от балды. Если вдруг товара не оказалось на полке, запускается процесс поиска ошибок в прошлом.
Прим. Шо за товаросопроводительные документы? Если ТОРГ-12, то в ней НЕ ОБЯЗАНА должна быть графа ГТД. См. альбом схем типовых форм.
(173) Может я чего-то не улавливаю, но чем это отличается по сути от стандартной реализации 1С, исключая расчет стратегии цен, который легко впихивается в обработку, создающую документ Установка цен номенклатуры.
(174) На "малотиражку" типа "получили большой объем товара на квартал-пол года" или ту же фармацию ставится цена с учетом цены конкретного поступления. К сожалению это их бич.
(175) КОНКРЕТНЫЙ ВОПРОС
21.01 - пришел ТМЦ1 по ГТД1 10шт.
22.01 - пришел ТМЦ1 по ГТД2 20шт.
24.01 - продали ТМЦ1 по ГТД1 5шт.

26.01 - продали ТМЦ1 по ГТД1 3 шт.
28.01 - продали ТМЦ1 по ГТД1 2 шт.
30.01 - продали ТМЦ1 по ГТД2 5 шт.

Вдруг обнаружили в процессе проверки, что 25.01 в базу был не занесен документ отгрузки поставщику, где был ТМЦ1 по ГТД1 1 шт.

Можно узнать ваш алгоритм корректировки данной ошибки?

А уже просто не знаю куда конкретнее.

(176) Вы забываете, что Вы выдаете клиенту не мифические торговые документы, а РЕАЛЬНЫЕ БУХГАЛТЕРСКИЕ. Поэтому схемы автоматизации торговли, где на при выписке первичке нет правильного бухучета работают хорошо, только если идет "мухлеж" с первичными напечатаными документами или пересорт по тем же ГТД в бухии.
Этот метод учета известен давно. ЧЕго его обсуждать то.

(177)

(178) У нас в свое время невыполнятелей поимели по самое нехочу. В документах отчетных надо было указывать и цену продажи, и и цену реестра, и цену завода-изготовителя/экспортера. Потому говорю, что видел сам. Так что "никто" не зачел ;). И это была сеть аптек, а не одинокая аптека ;).
(179) Я тебя еще заверю, что за ГТД бухи не столь сильно бьются, потому что реально часто в бардаке невозможно их контролировать.

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

(184) по (178) угу, потому что все-таки лекарства, отнесенные к жизненно-необходимым и именно поэтому аптеки или просят протоклы согласования цен чтобы там СТОЯЛА НУЖНАЯ ИМ НАЦЕНКА - потому как аптеки зачастую наценивают сами очень большой процент - или вообще не требут протоколов согласования цены... ;-)

(186) Скажу тогда совсем конкретно: та аптечная сеть, в которой я работал наценки соблюдала.
Я таки не понимаю, о чем тут речь: о программе, которая убавляет/прибавляет расходы/приходы на складе или же еще из нее надо доки покупателям печатать первичные?
И если мы кладем на ГТД и цену слабо привязываем к цене текущей партии, то вообще какие проблемы то? Какие последовательности? Вокруг чего пляски с бубном?

(186) Наценка строится от цены импорта, завода, реестра. Можно мухлевать, но все-таки это не так просто. Выше цены реестра +% не прыгнешь.

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

(189) Ну тогда тебе схема Владимира с учетом внутри склада не подходит ;).

Можно конкретную строку с движением 25-го числа? Пример же конкретен. И не забываем, что у клиента документ на руках и он уже уехал в Бобруйск-на-Дону.

(190) а извините, откуда у клиента на руках документ, если он по каким-то причинам не отражен в базе? если он выписан в какой-то учетной системе - то пусть там и вносят и исправляют, так как НА СКЛАДЕ количественный учет по ГТД - как мы уже обговаривали выше - в приницпе не нужен.... т.е. если у клиента на руказ док с UNL1 - который "забыли внести" - то
26.01 - продали ТМЦ1 по ГТД1 3 шт.
28.01 - продали ТМЦ1 по ГТД1 2 шт.
30.01 - продали ТМЦ1 по ГТД2 5 шт.
- выписывались клиенту в той же системе, в которой был выписан выданный на руки (но не внесенный) документ - и 11 штук ГТД получиться - не могло... - то есть или ошибка программиста/алгоритма или оформление доков в обход учетно/складской системы - это, сам понимаешь, не лечится...
.
а если вносить "забытый" документ 25 числа, то "спишется", ясен пень, например 1 шт "из прихода ТМЦ1 по ГТД2 20шт."

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

(191) Яху его знает. Напечатали ему и отдали. Вот. А в базу не записался док, спортился. Злыдни исправили случайно. Если эти варианты откинуть, то ошибок вообще быть не может. А значит и заднего числа. А значит ветка ни о чем ;).

Если тебя не волнует замена ГТД1 на ГТД2, то опять же непонятно, о чем тут весь спор в ветке?

... я конечно не "Владимир" ... хм ... "ОН" и сам выскажется ...

Моха но при чЁм тут ??? всё о чЁм Вы говорите ... ??? (вот так вот сразу - при чЁм ? ) ...

Владимир сделал некую систему "Склад-Магазин" ... ушЁл от стандартов универсально-глобальной 1С ...

Вы же его тяните обратно в 1С ... ДА! у них всЁ просто и может быть ОЧЕНЬ просто ... и хорошо ... и отлично ... они малость отказались от "детальной" точности в пользу 24*7 и "глобальной" точности ...

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

... возможно для Аптек, для импортёров и других видов нужен "СВОЙ" учЁт и свой "КОНТРОЛЬ" - вот о НЕМ и надо говорить ...

моЁ мнение: 1С ОЧЕНЬ универсальнА и глобальнА ... многим предприятиям эта универсальность и глобальность - обуза ...

... вот ...

... если Вам нужна ГТД и еЁ строгий учЁт возможно нужно дополнять данную систему ... и т.д. ... и т.п. ... ОН вам рассказал о СВОЕЙ системе ... ОНА, возможно не универсальна ... зато ИМ подходит...

... вот ...

(192) Я больше не могу это обсуждать. Мы кладем с прибором на доки в момент выписки, желая в момент получения отчетности получить плюшевую картину. Это сферический учет в вакууме.
Мы должны сразу понимать, что и как надо контролировать, а на что положить, чтобы получить нужный результат.
Контроль ГТД по количеству уже реализован в ТиС лет Х назад.

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

Моха обЪяни:

(195) ... ГТД, ГТД, ГТД ... что ужжж так ...
... заводим новую "старую"номенклатуру с ГТД - ушла номенклатура - ушла ГТД ... разв нет ... ? в чём сложности ведения учЁта ГТД ? ... обЪясни ! ...

(196) ... нууу... пусть это будет система складского учёта ... их то это устраивает ! ... для них система работает, то что им нужно они контролируют, получают, отписывают ... что тебя не устраивает ? ... обЪясни ! ...

... только, пожалуйста, с точки зрения системы а не типа "документ затёрли" или "забыли" ...

... вотОБЪЯСНИвотПОЖАЛУЙСТАвот ...

Контроль ГТД по количеству в тис - не реализован.
если от перераспределения сумм при партионном учете - это наши внутренние дела, то перераспределение ГТД в печатаемых документах без закрепления распечатанного (ТО ЕСТЬ УЧТЕННОГО) в "учете" с возможностью в любой момент такого учета "съехать" - вот это бяка... Правильный учет ГТД делается в полпинка - с нового года запущу у себя и выложу подробное описание.

(194)
"ОН, "подлец", НЕ хочет нам показать свою конфигурацию по тем или иным причинам"
Причины:
1) Это не моя собственность (решаемый вопрос).
2) Конфигурация имеет массу частных алгоритмов для нашей предметной области и эти алгоритмы "накроют" суть очень простых понятий (именно их мы и обсуждаем?).
3) В силу ограниченности (заточенности) ЯМД и ЯОД в 1Се приходилось "изворачиваться" для решения элементарных, по сути, алгоритмов большим количеством операторов.
4) Некоторые алгоритмы написаны не эффективно по скорости и это уведет обсуждение в плоскость "Давайте возьмем пяток типовых отчетов, нужных управленцам и заценим соотношения скоростей выпонения."(с) из (185). А мои аргументы типа "давайте выясним как часто, для кого и в какой момент нужна эта информация" сведутся к пустой болтовне. Приведу пример. К нам пришла посмотреть на систему "бухгалтер" из другой фирмы. Просит: "а покажите мне...". Показываем. "ууу-у как долго, в нашей системе мгновенно". Спрашиваем мы: "а сколько в вашей системе уходит времени на обслуживание клиента, подготовку сопроводительных документов, таскание взад-вперед товаров на складе, выверку остатков на полках и т.д.". Она либо не может назвать эти времена с присказкой "меня это не интересует", либо называет недопустимые времена для успешной работы бизнеса.
5) Некоторые куски написаны так, что они вызовут у многих программистов желание обсудить (покритиковать) наши знания русского языка или "высокой" теории программирования.
6) Я считаю, что если и обсуждать реализацию отдельных алгоритмов, то надо обсуждать сначала схему базы данных (в упрощенном виде). При разглядывании конфигурации понять схему базы данных очень сложно. Оно же написано на справочниках как единственном средстве "1С 7.7" в котором можно реализовать "нормальную" схему базы данных.

(196) по (194)
(Моха)
Это Вы так поняли, "что это система складского учета". Причины такого понимания могут быть во мне, могут быть и в Вас. Но я Вас заверяю, "что в этой системе еще и текущее состояние складов, резервов и т.п."(с) можно получить и использовать. И "из которой еще и доки клиенту можно выписывать"(с) соответствующие законодательству.
Я же не зря снабжаю свои тексты (мысли) информацией типа "работает с 2001 года", 50 пользователей", "свертку не делаем", "SQL сервер не используем" и т.д. Я это делаю не для того, чтобы похвалиться. А для того, что бы читающий мои тексты не подумал, что он общается (в моем лице) с сумасшедшим (прожектером, мечтателем) человеком. Конечно можно сказать "...я НИЗАЧТО НИКОГДА не поверю..."(с) из (155). Но тогда, думаю, и вести разговор не стоит...
Наша конкретная система имеет массу недостатков. Много чего не делает из того, что хочет получить от системы каждый из 150 человек имеющих доступ к "кнопкам" нашей системы.
Но в какой-то момент моей "жизни в АСУп-е" я осознал, что автоматизировать нужно не учет и документооборот, а суть процесса для которого существует этот самый учет и документооборот. Т.е. КТО и ЧТО "главный" в системе. И это было за долго до появления 1С (и как продукта и как фирмы).
Наверно, я зря "влез" в эту тему форума. Т.к. для тех людей которые это "осознают" я ничего нового не сказал, а для тех кто, пока еще, этого не "осознаёт" я говорил непонятные вещи.
Типа, мемуары я писал в этой теме форума. ;-)

P.S. Я от темы отписался...