trdm FinSoft
....поскипано......
На самом деле, это не так. В системах с проведением Вы раскладываете документ по регистрам (счетам) при проведении. В системах без проведения мы обрабатываем все документы, относящиеся к регистру (счету) в одном месте.......
....поскипано......

Проведение на самом дела синоним транзакции.
Оставлю без комментариев.
trdm Дополнительно (у нормального разработчика): проверки на правильность заполнения документа, анализ возможности провестись и т.п.
Я бы не стал отождествлять проверку валидности с генерацией проводок и нормальностью разработчика :-)
trdm Данные не дублируются, а интерпретируются в другую форму .
Лично я пользуюсь данной парадигмой уже много лет и не разу не пожалел об этом. Сопровождаемость и стройность системы остаются на приемлемом для дальнейшего обслуживания уровне.
В чем отличие понятий дублирование и наличие двух форм представления одних и тех-же данных? Для эффективного доступу к данным совсем не обязательно проводить документы, достаточно оптимизировать структуру базы данных. В рассматриваемой платформе, увы, эти возможности сильно ограничены, можно сказать, практически отсутствуют. Поэтому в контексте разговора об этой платформе я воспринимаю использование проведения документов в УУ как намеренное решение в пользу универсальности и унификации, жертвуя при этом потребительскими характеристиками. Это нельзя однозначно назвать "хорошо" или "плохо", это прямое следствие используемой схемы дистрибьюции софта. Так же, как и отказ от проведения документов - прямое следствие альтернативной схемы дистрибьюции.
trdm FinSoftВ системах без проведения мы обрабатываем все документы у вас транзакции вообще используются?
С большим терпением - да :-)

trdm И честно говоря, уже достал твой гон на 1С-ку и псевдореклама твоей системы (все не читал).
Может ты в чем-то и прав, но глаза намозолил достаточно для того что-бы твои агрументы воспринимались нормально.
Зря Вы так. Нуралиевых я уважаю, а наш софт я нигде не рекламировал. Я описал альтернативные технологии, работающие без использования проведения документов. Это выстраданные решения, родившиеся в результате многих лет практического сопровождения конфигураций на любимой Вами платформе. И речь, разумеется, идет не об экономии пары байтов, а об уменьшении размеров базы данных в 3-4 раза и повышении производительности почти на 2 порядка. Зачем я это все рассказал? Наверно, в продолжении темы об альтернативных технологиях. Плохо, когда люди зацикливаются на чем-то и перестают думать. Удачи!

Roman Brunets
FinSoft пишет:
> Зря Вы так. Нуралиевых я уважаю, а наш софт я нигде не рекламировал. Я
> описал альтернативные технологии, работающие без использования
> проведения документов.

Гм... Боюсь вы неправильно понимаете понятие "проведение". Давайте
определяться с терминами. Мое видение: проведение документа это
отображение операции в учете. Двойная запись там или нет - неважно.

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

strizh
Так о чем спор, собственно ? О вкусе устриц ?
Мы спокойно и в конструктивной форме обсуждаем разные подходы к построению информационных систем :-) Поскольку изначально в данном треде речь идет про Нуралиевский проект, я спозиционировал понятие "проведен" именно к реализации в этом проекте. Все, что Вы написали, вполне разумно. У меня только возник вопрос по Вашей реализации проведения в бухгалтерском учете. Предлагаю рассмотреть типовую ситуацию. Ввели приходные накладные, продаем. Затем обнаружилось, что при вводе прихода оператор попутал товар, а в результате проведения себестоимость продаж сформировалась неверно. Возникла делема. Если изменить в приходе товар на правильный, то нужно пересчитывать продажи. Если корректировать текущей датой, то искажаются аналитические отчеты. Как Вы поступаете в этом случае? Если пересчитываете продажи, то сразу или оставляете "на потом", как в УПП? Т.е. как Вы пересчитываете для расходных накладных проводку Деб 90.2 - Кред 41 (по Российскому плану счетов)?

iscrafmFinSoft,
что вы стесняетесь сказать о каком проекте вы рассказываете? Интересно же узнать где это "у нас". Тем более вы оказывается и себестоимость после каждой транзакции считаете, и проводки не формируете и много еще интересных вещей делаете.
Себестоимость после каждой транзакции считается у автора, которому я отвечал. У меня она считается при формировании отчета динамически или в закрытом периоде в нагруженных разрезах. Постить суда ссылки на наш проект я не вижу смысла, извините. Но на конкретные вопросы по методике работы "по документам" ответить могу, задавайте. Лучше, конечно, в другом треде.

strizhFinSoftЕсли корректировать текущей датой, то искажаются аналитические отчеты. Как Вы поступаете в этом случае? Если пересчитываете продажи, то сразу или оставляете "на потом", как в УПП? Т.е. как Вы пересчитываете для расходных накладных проводку Деб 90.2 - Кред 41

Оператор получает 3.14159... от начальника, на почту админу (т.е. мне) уходит служебка, я пишу что-то типа:

begin;
select CancelRegister(id, 8) from m_documents
where registered and date_register >= '2 12 2009' and type = 2;
select RegisterM_Document(id, 8) from m_documents
where not registered and date_register >= '2 12 2009' and type = 2;
commit;

Все, инцидент исчерпан.

Шучу, на самом деле :)

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

iscrafm FinSoftiscrafmFinSoft,
что вы стесняетесь сказать о каком проекте вы рассказываете? Интересно же узнать где это "у нас". Тем более вы оказывается и себестоимость после каждой транзакции считаете, и проводки не формируете и много еще интересных вещей делаете.
Себестоимость после каждой транзакции считается у автора, которому я отвечал. У меня она считается при формировании отчета динамически или в закрытом периоде в нагруженных разрезах.

остатки тоже так же считаете?
Записи об остатках фиксируют закрытие периода. Например, мы выставляем остатки на 01.03.2009, корректировки документов до этой даты запрещаются. Все расчеты по документам делаются от ближайших остатков. В этом плане схема похожа на УПП. Если требуются корректировки в закрытом периоде, то документ остатков можно разутвердить, внести изменения и снова утвердить. В этом случае остатки будут пересчитаны и отклонения сохранены в базе данных. Работу других пользователей прерывать не надо. Чтобы было понятнее. Если мы формируем отчет с 15.03.2009 по 31.03.2009, то программа возьмет остатки на 01.03.2009, документы с 01.03.2009 по 14.03.2009 учитываются в остатках на начала периода в отчете, документы с 15.03.2009 по 31.03.2009 расчитывают обороты за период отчета.

iscrafm FinSoftПостить суда ссылки на наш проект я не вижу смысла, извините. Но на конкретные вопросы по методике работы "по документам" ответить могу, задавайте. Лучше, конечно, в другом треде.
а какой смысл сферических коней в вакууме обсуждать.
Я не настаиваю. Если интересно, то на вопросы ответить могу, если не интересно, то можем закрыть обсуждение.

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