Цитата:

А как собирать общий журнал? через UNION
А если видов документов 100?

Phoenix писал(а) 14. Января 2008 :: 11:12:

Наверное можно для таких целей делать что - то вроде регистра учета документов и писать туда на UPDATE шапки документа

Phoenix писал(а) 14. Января 2008 :: 11:20:

Не пожалуй получится тот же 1sjourn

1. Есть табличка с общими реквизитами
2. Есть таблички шапки документов и строки
3. Делаем тригер на INSERT Update для таблиц шапки документов и строки и в них обновляем общую таблицу

Phoenix писал(а) 14. Января 2008 :: 11:00:

Журн еще выступает как маяк транзакции. А обработка транзакций жизненно необходима.
прежде чем выкидывать какой-то компонент, необходимо решить по другому все задачи, которые этот компонент решал.  
Иначе нахватаемся дидлоков в новой системе и просто прийдем к другим проблемам.
Возможно, если рассмотреть понятие "Маяк транзакции" и поиграть с ним, то можно и понять как решить проблему.

Phoenix писал(а) 14. Января 2008 :: 12:00:

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

fez писал(а) 14. Января 2008 :: 12:07:

Что ты иммешь ввиду?
Всеравно без понимания "Что происходит" и "Что должно происходить" никуда не денешся...

ИМХО, общий журнал - зло, равно как и корректировка, удаление, проведение/распроведение документов. мУда (т.е. бесполезно выполненная работа) в терминах кайдзен
Эффективнее будет следующая схема: есть задача - есть стандартный способ ее решения - есть стандартные документы, в которых надо заполнить четко определенные реквизиты. Очень эффективен в данной концепции механизм бизнес-процессов, так как достаточно инициатору только запустить процесс, а наполнением (желательно по порциям) занимаются иные люди, ответственные за свой участок, при этом сохраняется информационная наполненность процесса, происходит лишь его более детальное описание, наполнение содержимым. Т.е. стоимость информации о процессе, а из нее и складывается стоимость информации о компании в целом, постоянно возрастает.
З.Ы. А в рамках 1С-подобной системы еще хорошо бы детально рассмотреть вопрос про проведение документа задним числом, например был приход товара, а через два месяца нам надо сделать возврат товара именно по этой накладной, тогда как при партионном учете - эта партия уже распродана, а у имеющейся партии закупочные цены существенно отличаются от бывших ранее.

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

Phoenix писал(а) 14. Января 2008 :: 12:28:

Конкретнее пожалуйстах, откуда "известно"? Источник? Время возникновения источника? Удобство источника? Вероятность ошибки источника? Объем времени/ресурсов на обслуживание источника?
Плюсы/минусы испточника?

Про устройство 1С на уровне таблиц и блокировками регистров у 1сМожно посмотреть в этой книжке: "Профессиональная разработка в системе 1с Предприятие 8.0"
авторы: "А.П.Габец. Д.И.Гончаров, Д.В. Козырев, Д.С. Кухлевский, М.Г. Радченко"
Толстая такая книжка
http://v8.1c.ru/metod/books/book.jsp?id=63

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

Один из вариантов гибких блокировок: sp_getapplock, sp_releaseapplock

Дык, опять таки ИМХО, потому и нужен класс типа "ПоставщикДанных", который и берет на себя всю работу с БД, с теми же блокировками (причем становится не важно - какая именно БД используется). Или по научному - реализация паттерна MVC (Model-View-Controlling)

Опять таки sp_getapplock, sp_releaseapplock это для MS SQL, а для других БД?

Выложил тут свои идеи по поводу Архитектуры платформы:
http://qt1l.sourceforge.net/forum/viewtopic.php?t=39

Ну давай обсудим, либо что ты понимаешь под "спустись на землю"

Мда, понятно. Чтож, удачи тебе в твоем проекте.
З.Ы. Из "ДАО Toyota" "Принимай решение не торопясь, на основе консенсуса, взвесив все возможные варианты; внедряя его, не медли (немаваси)" и я согласен с этим потому, что обсуждая - мы не затрачиваем никаких особых усилий. Поменять планы, структуры, концепции, которые у нас в голове - очень легко. А вот если сначала делать, а потом начать переделывать, то затрачивается уйма усилий на достижение результата, который может оказаться никому не нужным.
З.З.Ы. Ладно, не буду мешать уважаемому мной Дмитрию реализовывать проект. Сам участвовать, извини, не буду.