To: Garya

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

Оппоненты обратили бы на нее внимание, если бы фраза была конструктивной. Т.е. что получается? Есть база данных, она может быть в некотором смысле хорошей, а может быть плохой. Однако постулируется принцип, что узнать это невозможно с формальной точки зрения. Прекрасное обоснование для тех, кто плохо проектирует БД! Принципы должны быть конструктивными. Мне уже не хочется спорить о формулировках НФ, я для себя вижу в них смысл, Вы нет, ну да ладно. Оставим их в покое. Но, «король умер, да здравствует король»! Свято место не должно быть пустым. Не нравятся принципы НФ, введем другие, ибо потребность в подобных идеях существует. Пусть будут принципы оптимизации баз данных. Чтобы не спорить об их научности, согласимся даже на эвристические, лишь бы они помогали проектировщику и программисту создавать эффективные БД. Один из таких возможных принципов я уже назвал, это принцип минимизации БД относительно избыточности данных, т.е. БД должна быть в максимально возможной степени не избыточной, другими словами избыточность БД должна быть минимальной. Т.е. принцип не запрещает избыточность, просто говорит, чтобы не использовать ее без действительно крайней необходимости. Думаю, можно предложить и другие принципы, главное, чтобы они были конструктивными. Такой подход было бы обсуждать гораздо интересней, чем отказ от всяких принципов нормализации / отимизации.

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

Нужно различать бухгалтерские и оперативные проводки (накопительного и распределительного учета). То, что Вы говорите, относиться к бухгалтерским проводкам, которые сильно заточены под законодательство. Для остальных проводок неопределенность меньше, как правило, одни реализуются для собственных нужд предприятия. Т.е. первые делаются для «дяди», вторые для себя.

> Я уже многократно приводил на этом форуме пример с получением от поставщика насоса - есть
> накладная и есть счет-фактура. Какое должно быть отражение в учете? Если насос приобретен для
> собственного использования - то на счет 08 "Капитальные вложения" с дальнейшим прицелом
> отнесения в состав основных средств. Если насос предполагается включить в состав некоторого
> изделия, то на счет 10 "Материалы и комплектующие изделия". Если для перепродажи, то на счет 41
> "Товары". Куда именно относить, собственно в накладной информации нет и быть не может. Эта
> информация имеется "за пределами" формализованных документов - в договорах, в письмах, в
> законодательных и номативных актах, которые меняются каждый день. И, что самое главное, не
> только в документах, а просто в головах - в виде намерений на будущее, которые пока нигде и никак
> не зафиксированы. Приведенный с насосом пример далеко не исчерпывает всех нюансов. Насос
> может быть приобретен как транзитный товар для прямой поставки от импортного поставщика на
> экспорт. При этом на него переходит "транзитом" право собственности - поэтому он должен быть
> отражен в учете, но реально на территорию РФ он не попадает. Он не попадает также на наш
> реальный физически существующий склад. И у него нет НДС, который может быть взят в зачет. А
> еще насос может числиться в нашей собственности, но быть отдан для ремонта сторонней
> организации, и его реально не будет во время ремонта на складе. И еще много-много других нюансов
> и нюансиков...

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

> Вы хотите все варианты этих нюансов и нюансиков загнать в принципы нормализации?
> Если да, то этому желанию можно только улыбнуться... :)

Не знаю, после вышесказанного, этот вопрос имеет смысл? Заметите слова «принципы нормализации» на слова «хорошо спроектированную базу данных» и все станет на свои места.

> Однажды слышал озвученную одним мечтателем идею формализации всех требований
> законодательства - так вот та идея - только часть этой идеи... :)

В этом не вижу никакой необходимости.

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

Неправда. Назначение нормализации (или похожих принципов) оптимизировать БД. Оптимизированная, в т.ч. достаточно гибкая.

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

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

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

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

> Проводка - это операция отражения в учете содержимого документа.

Согласен, отсюда следует также вторичность проводки по отношении к операции документа.

> Отражение одних и тех же документов может быть разным.

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

> Отражение разных документов может быть одинаковым.

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

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

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

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

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

> Реально у каждого нормального предприятия каждый месяц случаются ситуации, которые не были
> изначально предусмотрены. Если по каждой из этих ситуаций бухгалтер будет звать настройщика
> программы, чтобы он изменил связи между сущностями, то он ни в жисть не сможет сдать отчет по
> НДС к 20 числу следующего месяца. Вместо того, чтобы звать настройщика, бухгалтер делает финт –
> он работает "от проводки". И все, настройщик спит спокойно в кресле, и бухгалтер спокойно сдает
> НДС в требуемый срок.

Такого не должно быть, это уже проблема программиста. Надеюсь у меня после полного внедрения такого не будет.

> Есть еще один важный политический нюанс, который некоторые "асунизаторы" не принимают во
> внимание. Это вопрос ответственности. Ответственность за отражение в учете несет бухгалтер, а не
> программист. Программист не должен и не может знать всех нюансов законодательства, вникать во
> все нюансы всех договоров и писем... Бухгалтер - это Цербер на вратах системы учета. Он знает то,
> что не знает никто. И применяя эти знания, он должен разложить информацию по полочкам в
> соответствии с этими знаниями.

В принципе так.

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

У меня «автоматизация учета» не подразумевает «исключения бухгалтера из системы». Про вопрос ответственности я хорошо знаю. Меня самого иногда заставляют подписываться под отчетами моей программы, но принципиальные вещи подписываю не я. По моему мнению, пользователь системы, в данном случае ответственный специалист – бухгалтер должен иметь ПОЛНУЮ свободу действий по ведению учета. Если иногда это и не так, меня зовут и я исправляют ошибку.

> И еще несколько слов вдогонку... Я сам работал бухгалтером и имел дело с налоговыми
> инспекторами. Грамотный инспектор пытается "мимоходом" определить принципы организации
> учета - с помощью какой программы, что расчитывается автоматически... Старается получить
> перечень таких автоматических расчетов. И по каждому такому автоматическому расчету пытается
> обнаружить именно нюансы, которые в нем не предусмотрены. Даже при наличии у бухгалтера
> возможности влиять на проводки, многократные на автомате выполняемые операции затупляют
> внимание бухгалтера, и именно на автоматизированных операциях чаще всего допускаются ошибки в
> работе. Я сам когда-то допустил такую ошибку - потом чуть не уволился от расстройства чувств.
> Одна-единственная проводочка, но с огромной суммой... Зачет НДС, которого не должно было быть и
> который произошел лишь потому, что я сам настроил проводку с автоматическим зачетом НДС
> потому что по 99.999% аналогичных операций НДС действительно должен браться в зачет. И сам же
> эту проводку выполнил - просто светофор в мозгу не сработал.

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

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

Я уже говорил, что у бухгалтера должна быть полная свобода действий. Лично я не успокоюсь, пока последний бухгалтер не будет удовлетворен : ) .

> P.S. А задавшему вопрос все-таки советую сходить по ссылке.

Полагаю, что ему уже от нахлынувшей информации должно быть плохо : ) .

To: Garya

> Некоторые проводки делаются на итоговые суммы, некоторые на отдельные позиции. По некоторым
> позициям делается совокупность проводок.

Установить соответствие операция или все операции расширенного (электронного) документа -> группа проводок это не помешает. Для соответствия операций из различных документов в группу проводок, нужно будет уже вводить специальный документ типа «Закрытие периода».

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

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

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

Ну, эти алгоритмы, после программирования зарплаты, кажутся детским лепетом… : )

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

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

> Например, истек срок исковой давности - делается проводка по списанию просроченной
> задолженности.

Можно ввести формальный документ «Истечение срока исковой давности» и даже указать источник ответственности, например главного бухгалтера, если необходимо.

> Основанием для подобной проводки является "бухгалтерская справка".

Не имеет значения, хоть устное распоряжение, которое тоже можно оформить как формальный (электронный) документ.

> "Бухгалтерская справка" - это такое "письмо" в совершенно произвольной форме, "размышления
> на тему..." - форма этого документа не поддается никакой системартизации... :) В общем, это
> простое текстовое сообщение, содержащее некий скрытый смысл. Однако, еще ни одна учетная
> система не научилась выуживать из текстовых сообщений СМЫСЛ... Хотя, должен признать, было
> бы здорово, если бы умела... :) Если кто сможет сотворить учетную систему с искуственным
> интелектом, то я от всей души его горячо обниму и пожму ему руку.

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

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

> Предложите обсуждение, насколько важно, что "избыточность БД должна быть минимальной".
> Сформулируйте понятие эффективности, наконец (может, какой-то новый термин придумаете,
> например, эмериффективность), и понятие "избыточности БД"

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

> (например, индексы сюда входят, может ну их нафиг?

Не хочется снова развивать дискуссию, только два слова. Индексы можно отнести к служебной информации БД, особенно автоматически формируемые и не включать их (рассматривать отдельно) в суммарный объем минимизируемой БД.

> А если для целочисленного поля со значениями 0-255 используем целый int, это избыточность?).

В некотором смысле да. Так в 1С77 для поля Id (уровень ядра) по жизни используется 6 символов 36-ричного индекса, а размер поля всегда 9 символов. Так что если убрать последние три символа в этом поле во всех справочниках любой базы данных 1С, то абсолютно ничего не потеряем, а объем данных сократим.

> Пообщаемся.

Возможно

> Только не надо в ней писать про нормализацию.

Этого не обещаю, все будет зависеть от результатов исследования.

To: Garya

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

Я тоже толкую про идею минимизации БД : ) . Только таблицу (журнал) бухгалтерских проводок, я все же планирую иметь отдельно, независимо от других проводок (накопительного и распределительного учета). Скажу по секрету, в действующем ныне модуле по учету зарплаты я планирую помимо проводок по отчетным периодам сотрудника ввести еще проводки по зачетным периодам (в подчиненных таблицах справочника «Сотрудники»). Конечно, их можно вычислять автоматически при расчете з/п, но на это тратится много времени, поэтому в своей новой версии УЗП будет вместо одного журнала проводок два. Самих журналов (таблиц) документов в моей программе тоже два, для первичных и вторичных (расчетных), хотя все они имеют одну и ту же структуру. Даже в 1С предусмотрен 1 журнал расчетов, а их у меня фактически 4! Наверное, после всего сказанного в этом топике (ветке) мной относительно минимизации БД это будет кощунством. Однако, выгодой будет скорость расчета и удобство работы (для меня во всяком случае) с БД. Т.е. я легко позволяю себе увеличивать объем базы данных, если взамен получаю определенные преимущества. Все сказанное я отношу к бухгалтерским и оперативным проводкам. Мне гораздо удобнее иметь дело с различными таблицами, пусть и с пересекающейся информацией. Да и соответствующие отчеты будет строить гораздо быстрее…