> Как я понимаю Проводка это бухгалтерское понятие и означающее примерно такое:
> Есть документ, например поступленее денег, но реально деньги отображаются в поступлении только > когда провести документ.
> 1. Правильно? Тоесть, что-то типа commit в БД.

Понятие «проводка» тесно связана с концепцией учета. В 1С реализована прикладная модель учета Братьев Нуралиевых, частично внедренная на уровень ядра 1С. Там своя идеология проводок, как записей в регистрах. Если говорить абстрактно, то проводки в принципе не нужны. Ведь из чего состоит учет? Из записи операций в таблицу (журнал) операций. Все, этого в принципе достаточно. Из этой информации вполне можно получить любую выборку данных при наличии достаточно мощного языка запросов (типа SQL). Если необходимо временно не учитывать данные, достаточно наличия простого признака: Учитывать/НеУчитывать. Проводка, по сути, это дублирование записей журнала операций. Хорошо, а зачем это нужно? Тут мы приходим к краеугольному камню – технологии доступа к данным. Т.е. к файл-серверу или клиент-серверу. В клиент-серверных системах должна отсутствовать избыточность данных, все расчетные данные и нужные выборки должны вычисляться на ходу – динамически. Для этого требуется мощный сервер с эффективной системой выполнения запросов (SQL-сервер). То бишь, грубо говоря, много вычислений, мало данных (в смысле избыточности). Зато клиент может быть «тонким» - простой системой оправления / получения запросов. Метод, сопряженный этому обычно реализуется в файл-серверных системах, к коим относится 1С77 и, идеологически, «восьмерка», хоть и претендующая на звание клиент-серверной или даже трехзвенной архитектуры. Естественно, формулировка для файл-сервера будет противоположной - мало вычислений, много данных (в смысле избыточности). При этом уже можно обойтись без мощного сервера и тяжелых вычислений, тем более, что пространство на диске компьютера сейчас дешево. Таким образом, проводки (для определенности в 1С) это способ ускорения получения нужных данных, особенно оперативных остатков и оборотов. Вместо того, чтобы вычислять эти данные в нужный момент (при вводе документа), можно сделать это предварительно, разнеся операции документов по соответствующим регистрам (это и есть проведение в 1С). Естественно, нужно следить за тем, чтобы дублированные данные соответствовали своим оригиналам. Вот, кстати, почему регистры в 1С скрыты от пользователя. На тему клиент/файл – сервер можно говорить много, но для ответа на поставленный вопрос достаточно.
Заметим, что еще никто не доказал, что «единственно правильная» прикладная концепция учета Нуралиевых является единственно возможной в 1С. Да, практически все программисты 1С следуют этой концепции явно или неявно. Отсюда часто и повод для ругани 1С. Но, возможно пойти и другим путем и использовать альтернативные методологии учета на базе только ядра 1С77. Что я например и делаю в собственных конфигурациях. Но это уже другая тема…

> В учетных системах понятие прводки используется везде где только можно.
> 2. Вопрос: а реально ли они нужны?

Да, если мы хотим на относительно слабой машине и простом (дешевом) ПО получать удовлетворительные результаты.

> 3. Почему нельзя что бы все "автопроводилось"? Тоесть если создал документ прихода ТМЦ, то сразу > ТМЦ появлялось на складе.

Для нормальных клиент-серверных систем так и есть.

> 4. Еще вопрос, как при помощи проводок решить такую задачу:
> Нужно при выдачи ТМЦ указивать какой именно экземляр ТМЦ нужно выдать (Допустим станки,
> которые имеют серийный номер, так надо выдать именно станок с серийным номером ХХХХ,
> который находится на складе)?

В моей конфигурации (для 1С77) по учету ресурсов я делаю проводки в подчиненных справочниках соответствующих ресурсов. Т.е вместо «тайных» регистров использую явные. Проведение у меня происходит на уровне каждого ресурса документа. Так что, при расходе, я выбираю не просто ТМЦ, а дебетовую операцию данного ТМЦ, таким образом, проблем у меня не возникает. Я даже могу сделать расход без прихода (отрицательный дебет), который затем могу аннулировать отрицательным кредитом. В общем, делаю, что я хочу, в отличие от подхода Бориса Нуралиева – делать, что он хочет.

> 5. Где нужно использовать проводки, а где нет?
> Например библиотека: при выдачи книг нужно документ проводить?
> И какой смысл не проведенной выдачи книг?

Есть движение ресурса – есть проводка, явная (файл-сервер) или неявная (клиент-сервер, возможно с «птичкой» Учитывать/НеУчитывать операцию). Не проведена, значит, нет операции, в данном случае книга никуда не выдавалась.

> 6. Может это просто исторически сложилось, так как первоначально разрабатывались бухгалтерское
> ПО.

Бухгалтерские проводки – это канонизированные оперативные проводки, с целью получения стандартизированной интегрированной отчетности, что достигается сведением всего к общему эквиваленту – национальным деньгам и использованию стилизованных объектов учета – бухгалтерских счетов…

To: Владимир (Каменный Гость)

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

> В современных условиях учет переживает достаточно серьезные потрясения.

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

> Проводка вещь обезличенная, ее все равно, как на данный момент учитывался НДС, по каким нормам > он зачитывался.

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

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

Ну, это, как посмотреть. Думаю, что с проводками мы определились, это явные копии операций, упорядоченные по другому принципу (не так как в документах), назначение которых чисто техническое – повысить скорость доступа к данным в системах, где отсутствует достаточно мощный SQL-движок. Что касается изменения законодательства, то я не вижу здесь особых проблем, наоборот, программисту должно быть интересней смоделировать систему, в которой он сможет упреждать законодателей. Достаточно просто хорошего абстрактного мышления. Но программистов не учат абстрактному моделированию, это конечно проблема. Однако думаю, выход есть - привлекать к программированию, абстрактных математиков, но не заоблачных гениев, оторванных от жизни, а скажем тех, для которых учеба на мехмате МГУ была вторым высшим образованием, где первым образованием могло бы быть производственно – техническое. Но это так, к слову. В принципе вся экономика была, есть и, наверняка, будет основанной на кусочно-линейных моделях. Достаточно разобраться только с ее степенями свободы. Другая проблема, у нас нет фирм сопоставимых с возможностями MicroSoft. Борис Нуралиев, правда, в одном из интервью сравнивал себя с русским Билом Гейтсом, хотя, откровенно говоря, до уровня Била Гейтса ему далеко. Возможно, концепция 1С хороша для получения коммерческой прибыли на просторах СНГ, но с точки зрения запрограммированной модели учета – далека от совершенства. Все-таки продукты лидера «мелко-мягких» на порядок более совершенны, хотя тоже коммерционализированны. Тем не менее, не все плохо в «Датском Королевстве», т.е. 1С. Чувствуется, что когда движок версии 7.7 делали профессионалы – это было круто, даже по сегодняшним меркам. Но пришло время, когда в идеологию учета вмешались «политики» и на уровне ядра 1С появились прикладные объекты, которым там совершенно не место, чего стоит только один объект «Календарь», который, судя по всему, делал студент-второгодник. Но даже в таком виде с 1C77 можно иметь дело – достаточно не использовать прикладные объекты ядра и, само собой разумеющееся, типовые конфигурации. Я долго искал альтернативу 1С как средству разработки конфигураций для учета на типичном предприятии, который в состоянии сделать один программист. Последней попыткой была возня с MS Visual Studio 2005. Хорошая вещь, но по большому счету это корпоративная среда разработки, одиночке (с амбициозными планами) там делать почти нечего. В итоге вернулся к конфигурируемому интерфейсу 1С + движок Visual FoxPro как системе быстрой разработки приложений для учета на среднем предприятии. Сила 1С это несколько человеко-лет правильного программирования, которые нужно потратить, чтобы создать ей достойную альтернативу. Поскольку фирма 1С пошла по пути «неправильного» программирования, то лидером ей быть уже не долго. Короче, ребенок (ядро 1С77) был вундеркиндом, а вырос вполне заурядный малый («восьмерка»), т.е. русский Билл Гейтс не состоялся, а жаль – ведь мог же.
Но я «малость» отвлекся :) . Вернемся к нашим «баранам».
Если из-за появления «новых разрезов учета» «задача становится в принципе не разрешимая», то впору уже задаться вопросом, а правильным ли мы идем путем, товарищи? Очевидная истина, что неразрешимых задач не бывают, бывают только неправильные подходы. Возьмем, например, учет ресурсов на 1С. Что может облегчить поставленную задачу (упреждение непредсказуемых изменений в законах по учету ресурсов предприятия)? Ну, во-первых, перейти на единую (универсальную) форму документа. Один документ – один алгоритм проводки, что сильно упрощает ситуацию по ее контролю. Далее разработка механизма универсального отчета. В Интернете уже имеются подобные системы для 1С (как внешние обработки). Но, по большему счету, все, что мне попадалась – фигня, поэтому пишу свою. Электронная форма документов – одна, а печатных может быть множество. Можно даже объединить весь учет предприятия в одной конфигурации. Для учета зарплаты будет уже своя форма документов, так они отражают учет в другой размерности (накопительный, в отличие от распределительного). Теоретически можно объединить и эти документы, но нет смысла – проще иметь дело с двумя пересекающимися прямыми, чем с одной плоскостью. Бухгалтерский учет здесь будет надстройкой, куда будет отображаться информация о проводках накопительного и распределительного учета. Налоговый учет будет сопутствующим. Техническая сложность может возникнуть, если законодатели захотят ввести учет двух различных видов НДС. Тогда придется вводить дополнительные подчиненные справочники. Подобную систему я разрабатываю у себя на предприятии. Учет зарплаты уже работает почти два года, учет ресурсов внедряю с этого года, бухгалтерский учет планирую ввести в этом году. Если законодатели умудрятся поставить меня в тупик, то это будет вызов мне как программисту – придется пересмотреть свою модель учета. Ну а реляционные базы данных способны вполне адекватно отображать соответствующую реальность, это доказано теоретически, так что принципиальных проблем не создадут, главное самому построить нормальную модель…

To: SergGol

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

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

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

Так как таблица (журнал) операций должен, по определению, содержать всю необходимую информацию, то проводки, формируемые на основе операций, являются либо чистой копией (в накопительном и распределительном учете) либо однозначным отображением (в бухгалтерском учете). Далее, дело за программистом. Как строго он собирается придерживаться принципов нормализации базы данных. Мощный SQL-сервер для того и существует, чтобы строить полностью нормализованную базу данных, практически без избыточности данных. Раз так, то в клиент-серверных системах проводка может быть отождествлена с самой операцией (стать ее изоморфизмом). Все необходимые вычисления и преобразования SQL-сервер может делать на ходу (динамически). Конечно, вы можете не следовать этому правилу, но это уже будет неправильное программирование, которым, например, сильно грешит 1С8. Другое дело, если вы используете не SQL-сервер, а что-то вроде «1C Database Engine for .DBF, .CDX». Поручать этому самописному движку что-то серьезное, значит зря тратить время. Поэтому, плюем на нормализацию и добиваемся скорости выборки данных любой ценой. Решением этого вопроса может служить, например, система регистров 1С77 (бухгалтерских или оперативных). Это уже так возвели в стандарт, что по-другому 1С-народ уже и не представляет, как работать с базами данных. В принципе это даже неплохая идея для слабого ПО, организованного как файл-сервер. Просто нужно понимать, что к чему, за что чем приходится платить.
А то, что бухгалтерия это канонизированный учет и, по сути, является надстройкой над реальным учетом, я уже писал. Нормализовать ее ли не нормализовать, это уже вопрос идеологии программирования и возможностей систем разработки. Можно на клиент-сервере или даже трехзвенной архитектуре эмулировать файл-серверную технологию доступа к данным (как это сделано, например, в 1С8) и говорить, что так и надо программировать. А можно взять 1С77 и честно ориентироваться только на файл-серверную идеологию, с осознанием того факта, что использование избыточности данных (нарушающую нормализацию данных) дает выигрыш в скорости доступа к оперативной информации. И самому тщательно отслеживать согласованность дублированных данных, не надеясь, что 1С77 сделает это за тебя (да, она это может, но у меня это будет лучше реализовано). Попутно замечу, что совершенно нет никакой нужды использовать «1C Database Engine for .DBF, .CDX». Я делаю проще. Подключаюсь к библиотекам Visual FoxPro и исполняю в 1С программы, написанные на VFP (которые часто размещаю в автономных текстовых файлах) различными способами. Я могу использовать два вида библиотек VFP (runtime'скую и IDE’шную), а программы VFP выполнять непосредственно, через COM-сервер (аналог OLE) или как внешнее приложение VFP. Могу использовать в 1С77 не только функции VFP, работающие с файлами и памятью, но и графические функции. Таким образом, абсолютно вся мощь объектно-ориентированного VFP доступна мне в 1С. Вы можете спросить, почему я тогда не пишу на чистом VFP? Сразу отвечаю, потому, что интерфейс в VFP программируемый, а в 1С конфигурируемый. А это две большие разницы, как говорят в Одессе…

To: Сергей Васкецов

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

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

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

Откровенно говоря, не понял вашу сентенцию. Что здесь «событие»? Документ? Или операция документа? Приведите пример, пожалуйста.

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

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

> 2. Я с трудом могу себе представить, как может работать система без некоторых "схем настройки".
> Примеры - схема счетов хранения, схема возмещения НДС, и т.п. Основные операции, которые на
> 90% учитываются однотипно (и это меняется крайне редко, если вообще меняется), проще
> реализовать в виде некоторой схемы, а не дублировать (несомненно очень важную!) информацию
> в каждом документе.

Речь не шла о копировании «схем настройки». Любые схемы потребляют значения, вот о них и идет речь. Копирование операции как проводки не всегда тождественно, в общем случае это сурьективное отображение, т.е. один вектор значений однозначно, но не взаимно-однозначно преобразуется в другой вектор значений (вкладываемый как в фиксируемую, так в динамическую схему).

> Потому вопрос дублирования информации в БД значительно сложнее, чем Вы описали.

Я не рассматривал «вопрос дублирования информации в БД», как таковой, речь шла только о проводке, которая обычно связана с дублированием информации и нарушением нормализации.

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

Согласен, что если программист достаточно квалифицирован и обладает способностями абстрактного моделирования программируемой реальности, то он может позволить себе роскошь отходить от концептуальных основ программирования. Только бы неплохо в таком случае явно сформулировать свою новую концепцию программирования, может быть даже в виде научной статьи, или просто обсудить на соответствующем форуме, с целью проверки на прочность новых теоретических идей. Еще Козьма Прутков говорил, что «специалист подобен флюсу: полнота его одностороння». Дело в том, что классики реляционных баз данных (тот же Кодд) были весьма не глупые люди, и они доказали логическую полноту этих БД, их способность адекватно отображать соответствующую реальность. Поэтому, сознательно нарушая нормализацию, нужно хорошо понимать, что теряется и что приобретается. Если сервер достаточно мощный, а база данных весьма и весьма огромна, то какое преимущество здесь можно получить, за счет избыточности данных, нарушения атомарности данных и других принципов нормализации? Ускорение доступа? Но сервер и так быстро все считает. Или что-то другое? Что же до «распределенных вычислений», то это не совсем учет в базах данных, это уже задача другого плана.

To: Dried Gagarin

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

Ну, во-первых, я никому ничего не запрещаю делать, и не навязываю своего мнения. Я сторонник свободы творчества. Мне, например, не нравится концепция прикладного учета братьев Нуралиевых, реализованная в 1С, я пытаюсь выработать собственные подходы. Для себя, прежде всего. Если вас не прикалывает «разбираться что нужно, что ненужно и что может понадобиться в ближайшем будущем», то и не делайте этого. Мне это интересно, поэтому и интересуюсь. А «канонизированный учет» здесь не употреблялся, как ругательное слово. Это констатация факта, причем в положительном смысле. Канонизация это признак научности, своего рода базис, точка отсчета и это правильно, так должно быть. Как «реализовать проще» бухгалтерский учет, я уже писал в предыдущем постинге. Свои собственные программы я же сам и внедряю и меня не прикалывает, если пользователю все сложно и непонятно. Я стремлюсь получать удовольствие от работы с собственными программами. И, впрочем, никому их не навязываю. Мне не нравятся чужие программы, я пишу свои. Поэтому если кому не нравятся мои программы, пусть использует другие.

> Верю, что спецы в каком-нить сапе, оракле и мелкософте способны это учитывать. Не верю, что
> это способны делать спецы в 1С, тем более вы. Ничего личного.

Типа, «нет пророка в своем отечестве» : ) . 1С смогли сделать то, чего нет у «мелкомягких». Их конфигурируемый интерфейс справочников и экселоподобная система отчетов в 1С77 у меня до сих пор вызывает восхищение. Из-за этого я и использую 1С77. Но для эффективности привлекаю внешние компоненты и библиотеку Visual FoxPro. Получается очень здорово. Я же в отличие от вас сомневаюсь, что «спецы в каком-нить сапе, оракле и мелкософте способны это учитывать». Иначе у нас бы все работали на этих системах (поломали бы если надо). Это все корпоративные системы разработки и ориентированны на большой западный бизнес. У нас же ниша учета на малых и средних предприятиях занята в основном 1С. По праву, между прочим, как бы их не ругали. Да, вероятно, такое дело будет не вечно и 1С скоро вытеснят из рынка. Но это будет уже по их собственной глупости. Имея соответствующие ресурсы, я бы попытался это сделать также. Рано или поздно такие люди с правильными идеями и ресурсами найдутся, прецеденты уже есть, хотя и не очень пока удачные.

To: SergGol

> 1. Он канонизирован по праву, а не по чье-то прихоти.

Я и не утверждал обратного.

> Он и есть реальным.

Позвольте с вами не согласится. Имея все данные по накопительному и распределительному учету, я могу автоматически построить бухгалтерский учет, со всей требуемой отчетностью. Но обратного я сделать не могу. Если я веду чисто бухгалтерский учет, то полноценной картины по учету ресурсов и зарплаты не получу. Ибо бухгалтерские проводки/операции строятся с частичной потерей информации.

> 2. Выскажу крамолную мысль. С некоторой точки зрения необходимо пожертвовать быстродействием
> для достижения прозрачности настроек учета. Вот на практике и выходит, что данные ложаться в БД
> и извлекаются оттуда через несколько слоев "прокладок". Скорости это действительно не добавляет,
> но появляется гибкость и ясное осознание того, что откуда берется без необходимости "ковырятся"
> во внутренностях. И отделение проводок от первичных документов и есть одной из таких прокладок.

Тут я с вами тоже не согласен. И если хотите, пытаюсь доказать это в собственной разрабатываемой конфигурации по полному учету на типичном среднем предприятии. На эту тему я уже писал здесь.

To: Silent Majority

> Сначала информация попадает в торговую или складскую (учетную) программу. Поэтому часто
> бывает удобно реализовать экспорт данных из учетной программы в бухгалтерскую.
> Достаточно передавать только суммы для проводок, но на практике в 1С бухгалтерию все просят
> передавать документы с номенклатурой и реквизитами контрагентов. Получается дублирование
> информации, но зато бухгалтер получает свободу маневра, тем более что в бухгалтерии не всегда всё
> совпадает с реальностью. Да и спокойнее бухгалтеру, когда в его программу не вводят информацию
> все кому не попадя :)

Типичный пример, когда теоретические, концептуальные моменты программирования, программист получает самостоятельно, методом проб и ошибок. Потому видимо и мало хороших учетных программ, раз каждый должен пройти долгий путь экспериментов. Борис Нуралиев как-то заметил, что только в России существует порядка 200000 различных конфигураций по учету и расчету зарплаты. Интересно, почему каждый программист должен переоткрывать Америку? Может быть, неоходимо уже ставить вопрос перед политиками, а не пора ли от дезинтеграции общества переходить к его интеграции?

To: drunk2

> запутался с дебетом/кредитом. поправьте, если не так:
> заказчик(кредитор?) должен конторе(дебитор?) деньги за услугу.
> контора(кредитор?) должна деньги исполнителю(дебитор?) деньги за услугу.

Все началось с приращения, как разности двух величин. Естественно, она может быть отрицательной и положительной. Для удобства учета положительных и отрицательных приращений были введены их эквиваленты: дебет и кредит. Т.е. дебет – это, в общем случае, положительная часть приращения некоторой величины, а кредит – отрицательная (с положительным знаком). Конкретный смысл дебета и кредита в бухгалтерии определяется номером бухгалтерского счета. Т.е. дебет может быть и в нашу пользу и не в нашу, тоже и для кредита, обычно это связано с тем пассивный или активный счет. Для счетов обоих типов может быть и то и дрогое.

Кстати, вопрос на засыпку. Может ли дебет и кредит быть отрицательным?

To: Dried Gagarin

> А что это тогда? Вот это ваше высказывание и понимание того, что один и тот же первичный
> документ по РСБУ и по МСФО будет отражен разными проводками вызывает у меня когнитивный
> диссонанс.

Я не знаю что такое «РСБУ и МСФО». Сам я не местный :) . Но проблемы я не уловил. Вы можете сформулировать проблему точнее?

To: Сергей Васкецов

Интересно, а товарищ Молод читает, ответы на свой вопрос? А то его ветка стала уже жить самостоятельной жизнью : ) .

> Из этого следует, что по проводке (а сколько проводок может быть у одного документа, и
> наоборот?) всегда можно восстановить документ.

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

> Внимание, вопрос знатокам! Зачем тогда пользоваться документами, если можно сделать удобную
> "морду" для редактирования проводок и пользоваться только ими?

И об этом я уже здесь писал, в противоположном смысле, правда.

> Милый друг, здесь все куда сложнее.

Для вас…

> Более того, вы оперируете слишком сложными дял Вас понятиями.

Пожалуй, наоборот, понятия слишком сложны для вашего восприятия.

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

Я эту систему строю по определению, не умозрительно, а в реальной программе, которая работает на реальном предприятии. Все равно, что доказывать постулаты…

> Также не совсем ясно, что вы понимаете под термином "эквивалентность"?

Взаимно-однозначное соответствие. Изоморфизм я понимаю в этом же смысле. Хотя бывают и другие определения изоморфизма.

> Ибо то определение изоморфизма, которое я помню со времен обучения в МФТИ, не укладываются
> в Вашу логику (скорее, Вы все же неверно используете термины).

Ваше определение в мою логику? Свои определения я дал, а вы скажите свои!

> Это вообще нонсенс. Вы вообше знаете, что такое "функция" (особенно "не вполне однозначная"
> или "вполне не однозначная")?

Если вам хочется считать, что не знаю, пусть будет так : ) . В данном случае слово «вполне» использовано как усилительная конструкция к слову «однозначная» или «не многозначная», т.е. считайте, что я просто подчеркнул слово «однозначная». Вообще-то я считаю это признак слабости, цепляться к словам. Мы все допускаем вольность речи. Другое дело, если бы речь шла о научной статье, к тому же опубликованной. Спорьте по существу. Я бы на вашем месте сначала поинтересовался моим образованием.

> Если да, давайте сначала определимся, в каких математических пространствах мы работаем и
> совпадает ли пространство документов с пространством проводок
Нет, не совпадает, я не давал повода думать иначе.

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

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

> К Вашему сведению, единица (а она не бывает тождественная или не тождественная) и единичное
> преобразование - это разные вещи.

Согласен, я говорил с точностью до изоморфизма. Математик меня поймет. Пример, векторный ноль и скалярный ноль, принципиально разные вещи. Однако любой математик может написать равенство вектора скалярному нулю, и никто к нему цепляться не будет, так как все понимают, о чем идет речь.
(Только, пожалуйста, не цепляйтесь к словам «ноль» и «нуль».)

> 1. А почему Вы решили, что этим все варианты исчерпываются?

Я этого не говорил. Если, я говорил только об «а» и «б», а существует еще «с», то это не значит, что все исчерпывается только «а» и «б». На вашем месте я бы просто спросил, а что вы думаете о «с»?

> 2. Бухучет - только один из видов учета. То, что Вы описали, будет верно, если выполняется любое
> из следующих условий: а) программа изначально рождена как бухгалтерская и УУ,НУ, МСФО и
> прочие "радости жизни" докручивались "потом и сбоку"; б) в программе только БУ. Во всех
> остальных случаях это просто неверно.

Ладно, я уже устал, пусть будет так. Только, не понимаю, как это «неверность», повлияет на работу моей программы, принципы которой я здесь излагал. Если я обнаружу ошибку в ней, я ее просто исправлю. Рекомендую вам в доброжелательном споре искать, прежде всего, положительную информацию, а уже затем отрицательную.

> А Вы ничего не слышали про бритву Оккама и "на всякого мудреца довольно простоты"? Это
> простейшая структура и она реально работает. А если нет разницы - сами знаете что.

Вы совершенно не улавливаете тона моих сообщений, все перекручиваете с точностью до наоборот…

> И вообще, слово "зарплата" здесь важное или нет? Где здесь смысловой акцент?

Да, это важный пример накопительного учета.

> Это Вы так думаете? Боюсь предположить, что Вы явно не в теме.

Тоже перекрутка…

> Но ответ на него очевиден. Устраивают. У меня, кстати, возникает встречный вопрос. Много Вы
> знаете систем, где проводка как таковая отсутствует и, например, главная книга или сальдово-
> оборотная ведомость по дебиторке/кредиторке по контрагентам собираются только по документам?

Возьмите типовую конфигурацию «Бухгалтерский учет» и не пользуйтесь документом «Операция» (здесь я говорю в терминах типовой «БУ»). Получите все, о чем говорите. Кроме того, я работаю над подобной системой, где сделана уже большая часть, которая реально внедрена (но по ходу развивается и совершенствуется).


> Возьмите ПБУ18/02, отличия в БУ и НУ ОС-ов или еще лучше, отличия РСБУ от МСФО.
> Например, потратили деньги в сумме 100 денег. и что-то купили на них, было это это 01.01.2001.
> В БУ это отражается, например, в сумме 90 денег*курс за дату 20.01.2001, 10 денег*курс за дату
> 25.01.2001 и еще 5 рублей за 31.01.2001. В НУ отражается в сумме 500 рублей за 02.2001. В УУ
> отражается за день операции на сумму 100 денег и на 31.01.2001 на -100 денег. А по МСФО вообще
> не отражается. Не надо спрашивать, что это за бред, в жизни еще не такое бывает. Вот моментом
> учета события (траты денег) в разных учетах (БУ,НУ,...) и определяются различные сущности
> проводок.

Сложно, но не принципиально. Я уже говорил, что сам я не местный (с Украины). Но у нас своих бзиков тоже хватает. Думаю, ваш случай не повлиял бы на принципиальное изменение моей программы. Всего то делов, построить из данных документов (приход товара / расход денег) несколько вариантов проводок в разных местах. Это мой принцип: операции документа первичны, проводки вторичны, даже если проводки (в некоторых случаях) тождественно совпадают с операциями.

> Документ - это информация, которая требуется для идентификации события.

Согласен, только достаточная информация.

> Проводка - это отражение документа (в итоге - произошедшего события) в каком-то учете.

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

> Утверждение документа означает факт совершения события.

Для этого достаточно «псисы»: Учитывать/НеУчитывать в операции (ресурса) документа.

> Утверждение проводки означает факт принятия события к какому-то типу учета.

Если операция документа проведена, то соответствующая ей группа проводок (в том числе бухгалтерских) также должна быть автоматически проведена. Отмена проведения проводок должна осуществляться автоматически только путем снятия «псисы» у соответствующей операции документа. Это то, что я реализую. Вы же можете использовать другой механизм проводок.

> В качестве домашнего задания рекомендую почитать НК в части учета доходов и расходов для
> определения налогооблагаемой базы по налогу на прибыль и сравнить это с ПБУ5/01,6/01 и другими.

У нас своего законодательства хватает, но уже читаю, как художественную литературу : ) .

> Я не писал, что она первичная и независимая.

Я говорил «в смысле».

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

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


> Вы опять не к месту употребляете умные слова и допускаете логические ошибки. Давайте проще.
> Когда вы покупаете товар X, он всегда учитываются на счете хранения Y. Вопрос! Зачем в документе
> указывать счет Y, если он всегда один и тот же, но может очень редко, но поменяться пару раз за всю
> жизнь?

Я просто ссылаюсь на товар Х и информацию о счете беру по ссылке у этого ресурса. В документе я просто показываю ссылку Х.Y, на тот случай, чтобы видеть, что счет не пустой и правильный.

> 1. То есть, проводка не в БД?

В БД.

> 2. Какую нормальную форму нарушает пара (документ+проводка)? И пожалуйста, в терминах
> реляционной алгебры, а не на пальцах.

Из всего вышесказанного это должно быть очевидно. Нарушает 3-й принцип нормализации базы данных, который в некотором смысле эквивалентен утверждению, что база данных должна быть минимальна по объему (данных).

> Чего-чего? Где такую траву покупаете?

Хороший метод спора, надо принять его на вооружение : ) . Я вполне допускаю нестрогие высказывания, но не говорю явный бред. Обычно, пережевывая в памяти спор на досуге, я довольно часто переформулирую свои высказывания. Даже концепцию и глубокую перестройку своей программы я изменял не однократно. И это нормально, не ошибается тот, кто ничего не делает. Не надо только мои слова воспринимать слишком буквально, ибо я не Мессия. Очень редко, кто может явно изменить мои взгляды, обычно я делаю это сам под воздействием косвенной информации, после ее переосмысления. А моя программа будет работать скорее по моим принципам, чем по вашим. Как говорил Карл Маркс: «Практика – критерий истины». После этого вы будете мне доказывать, что моя программа, о принципах которых я здесь так много говорю, работает неправильно.

Чтобы по общим концептуальным вопросам баз данных мы спорили более по существу, рекомендую вам почитать доклад С.Д. Кузнецова «Три манифеста баз данных: ретроспектива и перспективы» на международной научной конференции "Базы данных и информационные технологии XXI века".
см. http://www.citforum.ru/database/articles/manifests/

> Может, Вы все-таки поверите, что бывают случаи, когда оказывается, что не достаточно быстро или
> конкуренция за ресурсы оказывается слишком большая?

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