Уважаемейший Олл!!!!


Во первых про аналитики. Т.е. единственное решение (ИМХО конечно) это сделать плоскую таблицу (id_проводки, дебет, кредит, сумма, аналитика1, ... аналитикаN) НО таблица получается громоздкой. В ней всяких пустот образуется немерянно так как разные счета имеют разные аналитики. Дальше хуже. (Ну уж я не говорю о тяжеловестности запросов, в смысле оптимальности выполнения и тяжести создания запросов и количества нужных индексов — хотя диски сейчас дешевы). А вот то-что количество аналитик оказывается жестко фиксированным это плохо, так как по некоторым сведениям если организация начинает наращивать количество аналитик по счетам то их возрастание происходит экспоненцияльно!!!. А писать динамические запросы которые позволят вам менять количество аналитик это получается такоооооой изврат, что самому тошно становиться (пробовано на MSSQL7). Есть некое шестое^2 чувство что просто структура таблиц должна быть совсем не такой как в классическом варианте плоского журнала проводок. Но вот какой — сие есть тайна!!! По крайне мере пока. Это и заставляет искать хоть что-то (любую информацию). И кстати!!! Еще есть проблема откатов и удалений из журнала проводок. Воооот проблемка! мне начинет казатся, что здесь уже начинает играть роль фундаментальные ограничения баз данных — то что кортежи (записи) должны быть взаимонезависимы. А если мы хотим изменить историю проводок задним числом то получаем что у нес "поедет" все последующая история. За сим "поедет" крыша у кое-кого еще (програмиста, бухгальера, начальника — по вкусу выбрать :) а также "поедут" доходы в виде зарплат огромных в вечнозеленых единицах и проча, и проча..., и проча... :( (тут уже говорилось о весьма актуальной, современной и социально значимой проблеме нехватки денег на мерседесы банковским зампредам). Так что кто чем может просьба помочь (чуть не добавил не корости ради а токому любопытства для!!!) :no:

Здравствуйте Tiger, Вы писали:

T>Уважаемейший Олл!!!!


T>Во первых про аналитики. Т.е. единственное решение (ИМХО конечно) это сделать плоскую таблицу (id_проводки, дебет, кредит, сумма, аналитика1, ... аналитикаN) НО таблица получается громоздкой. В ней всяких пустот образуется немерянно так как разные счета имеют разные аналитики. Дальше хуже. (Ну уж я не говорю о тяжеловестности запросов, в смысле оптимальности выполнения и тяжести создания запросов и количества нужных индексов — хотя диски сейчас дешевы). А вот то-что количество аналитик оказывается жестко фиксированным это плохо, так как по некоторым сведениям если организация начинает наращивать количество аналитик по счетам то их возрастание происходит экспоненцияльно!!!. А писать динамические запросы которые позволят вам менять количество аналитик это получается такоооооой изврат, что самому тошно становиться (пробовано на MSSQL7). Есть некое шестое^2 чувство что просто структура таблиц должна быть совсем не такой как в классическом варианте плоского журнала проводок. Но вот какой — сие есть тайна!!! По крайне мере пока. Это и заставляет искать хоть что-то (любую информацию). И кстати!!! Еще есть проблема откатов и удалений из журнала проводок. Воооот проблемка! мне начинет казатся, что здесь уже начинает играть роль фундаментальные ограничения баз данных — то что кортежи (записи) должны быть взаимонезависимы. А если мы хотим изменить историю проводок задним числом то получаем что у нес "поедет" все последующая история. За сим "поедет" крыша у кое-кого еще (програмиста, бухгальера, начальника — по вкусу выбрать а также "поедут" доходы в виде зарплат огромных в вечнозеленых единицах и проча, и проча..., и проча... (тут уже говорилось о весьма актуальной, современной и социально значимой проблеме нехватки денег на мерседесы банковским зампредам). Так что кто чем может просьба помочь (чуть не добавил не корости ради а токому любопытства для!!!)

Как-то занимался этим вопросом. Можно создать классы(таблицы) для всех счетов с аналитикой по ним (то есть решается вопрос с добавлением аналитики), то есть всё пока что хорошо. Но тогда проводка Д К — это уже ID таблицы, ID в таблице для дебета и ID таблицы, ID в таблице для кредита. Явный облом. Поэтому как-то на ум пришло: необходимо создавать ОО слой, который будет отвечать за формирование запроса для таких проводок. Но это мне пришло на ум уже после того как я закончил работать на своего бывшего работодателя, так что чем всё должно закончиться пока не знаю

Здравствуйте , писали:


T>>НО таблица получается громоздкой. В ней всяких пустот образуется немерянно так как разные счета имеют разные аналитики.
можно создать несколько таблиц из ходя из специфики производства для часто используемых счетов в любом вареанте:
например только для счета 51 или
только для проводок счета 51 и счета 60 и т.д.
Таблицы можно создавать "динамически", исходя из некоторых пкритериев:
а) организация дошла до опр. объема операций
б) чаще всего используются счета т и n — выделяем в отдельную тадлицу
в) ....

>Есть некое шестое^2 чувство что просто структура таблиц должна быть совсем не такой как в >классическом варианте плоского журнала проводок.

что можно выдумать кроме журнала проводок?

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

Здравствуйте Аноним, Вы писали:


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

Да Вы совершенно правы.... И я просто всецело с Ваыми согласен. Ничего не должно быть изменено задним числом, это теория учета. Период закрывается и все. Все исправления делаются только исправительными проводками (или исправительными работами на срок от... :), но не будем отвлекаться). Если бы было так тоя просто рыдал бы от счастъя. Однако, суровая реальность не такова. Иррациональный мир заказчиков и пользователей ну никак не хочет принимать таких смешных ограничений, что доказывает некую исскуственность теоритических изяществ. Не оскудела страна наша самобытными Кулибиными и талантливыми Левшами, что есть, несомненно, хорошо — наличие в учетных системах возможности откатов и удалений (разумеется в чисто образовательных целях :) давно стало стандартом де-факто! Такая возможность позволяет другим Кулибинам (уже от мира финансов)... ну вообщем позволяет, в чем нетрудно убедиться по количеству мерсов на улицах:). Кстати, если найти математический алгоритм автоматического проведения откатов и удалений то это вообще открывает широчайшие возможности. Например теоритически возможно создание некой программы (разумеется в чисто образовательных целях — уж образованными будем!!! "Будем крем Марго кушать, в батистовых портянках ходить" Ильф и Петров (с)), которую можно назвать например TaxOptimazer Gold PRO v. 7.1 или Taxator Paradize (жаль в рамках форума нельзя объявить конкурс на наиболее пошлое название). Вообщем которая искала бы как можно изменить суммы проводок (среди заранее определенного круга операций, так как все же не все значения сумм проводок можно менять без расхождения учетных данных с данными первичных документов) что-бы свести уровень налогооблагамой базы, а следовательно и уровень налогов до заранее определенного уровня. Во как. То есть пользователь задает уровень налогооблажения, который ему благоугодно оплачивать и под конец отчетного периода получает тщательно "оптимизированный" журнал проводок (я прям вижу этот наборный счетчик в диалоге с названием "Задание уровня налогооблажения" и еще поле для задания уровня эвристик — Вот это алгоритмы!!! разумеется в чисто образовательных целях :).


Точка сборки совсем расшаталась.. пойду приму валерианки.
:crash:

Здравствуйте Tiger, Вы писали:

T>Здравствуйте Аноним, Вы писали:


T>Ничего не должно быть изменено задним числом, это теория учета. Период закрывается и все. Все T>исправления делаются только исправительными проводками (или исправительными работами на срок T>от... , но не будем отвлекаться). Если бы было так тоя просто рыдал бы от счастъя. Однако, T>суровая реальность не такова. Иррациональный мир заказчиков и пользователей ну никак не хочет T>принимать таких смешных ограничений, что доказывает некую исскуственность теоритических изяществ.
Вв думаете легко переписывать с-о ведомость (простеню) ... значет за какой период времени да по нескольку раз.
Чтобы не заниматься такой ерундой есть спец. методы.

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

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

Здравствуйте Mishka, Вы писали:

M>Есть мысль, чтоб не мучиться хранить журнал проводок не в форме массива, а в форме списка. То бишь если вставляем проводку куда-то в середину, то хотя бы будем знать с какого момента всё надо пересчитывать.

M>А что касается внесения изменений вместо сторно, так это всегда приветствовалось. На то он и есть компьютер, чтоб юзеры ошибались :user:
Не получиться :( так как во первых речь идет о таблицах (на уровне СУБД — так как ведь проводки не только нужно хтро считать, но еще и хранить в базе MSSQL). Можно это конечно организовать список в таблицах, т.е.одна запись зависи от другой (но бог мой какой это стрем!) но не выдет все-равно так как в зависимости от изменения праметра проводки (суммы т.е. или перераспеределения сумм по аналитикам) могут порождаться совершенно разные операции. Это даже в виде карты (как дополнительная таблица реализующая отношения многие ко многим для проводок) не очень то выходит. Грусно все это. Поэтому это и наталкивает на мысль (причем чем дальше тем больше что журнал проводок на уровне СУБД нужно как то очень хитро.) Но черт возьми должны же быть какие-нибудь книги, фундаментальные труды по этому вопросу (ведь по любым областям есть) значит по учету просто обязаны быть. Вот многоуважаемейший Willi имел смелость спросить но обсуждение ушло в сторону. Кстсти ваша мысль с отдельными таблицами к каждому счету — в ней по моему есть что-то интересное. Надо подумать. Спасибо :crash:

Здравствуйте Tiger, Вы писали:

T>Уважаемейший Олл!!!!


T>Во первых про аналитики. Т.е. единственное решение (ИМХО конечно) это сделать плоскую таблицу...

Не единственное. (см. http://www.rsdn.ru/forum/message.asp?mid=29760&only

Автор: VladD2
Дата: 19.02.02

)

Здравствуйте Tiger, Вы писали:

T>Да Вы совершенно правы.... И я просто всецело с Ваыми согласен. Ничего не должно быть изменено задним числом, это теория учета. Период закрывается и все. Все исправления делаются только исправительными проводками (или исправительными работами на срок от... , но не будем отвлекаться). Если бы было так тоя просто...

Мужик! Вся страна уже восемь лет так работает. И без твоих алгоритмов, а ты только проснулся.

PS

Если на базе базы . Посчитан и сддан баланс, то менять ничего нельзя. Это я тебе говорю как практик сдававший балансы, а потом матерясь искал, что я там наизменял задним числом. Не мелочь разную (аналитику, коментании и т.п.) менять конечно можно, но радости от этого никакой. А если ты баланс не сдал, то меняй что хош. Нужно знаьб кто что менял? Ну, дык создай таблицу в которой лог изменений записываться будет (как в твоем любимом MSSQL7). А пересчитывать в соверменной системе (созданной на современный средствах) ничего не нужно. Просто забудь о спец таблицах с закешированными расчетами. Как при этом жить? А выбрасить нахрен MSSQL7 и поставить MSSQL2k или Оракл. В них есть индексированные/материализованные view, которые пересчитываются автоматом (и очень быстро).

PPS

Повторяю еще раз все ваши пороблемы от неправильного проектирования.

Здравствуйте VladD2, Вы писали:

VD>Мужик! Вся страна уже восемь лет так работает. И без твоих алгоритмов, а ты только проснулся. :)
Да нет, я имел ввиду автоматизацию процесса... :))

VD>Если на базе базы :). Посчитан и сддан баланс, то менять ничего нельзя. Это я тебе говорю как практик сдававший балансы, а потом матерясь искал, что я там наизменял задним числом. Не мелочь разную (аналитику, коментании и т.п.) менять конечно можно, но радости от этого никакой. А если ты баланс не сдал, то меняй что хош. Нужно знаьб кто что менял? Ну, дык создай таблицу в которой лог изменений записываться будет (как в твоем любимом MSSQL7). А пересчитывать в соверменной системе (созданной на современный средствах) ничего не нужно. Просто забудь о спец таблицах с закешированными расчетами. Как при этом жить? А выбрасить нахрен MSSQL7 и поставить MSSQL2k или Оракл. В них есть индексированные/материализованные view, которые пересчитываются автоматом (и очень быстро).

Но я же писал об УЧЕТНЫХ системе а не о бухгалтерской. Сейчас рулит понятие управленческого учета когда хозяева компаний хотят видеть реальное положение вещей в компании. То что когда сдан в налоговую баланс и в этом периоде изменять ничего нельзя это как бы очевидно. Но вот например представим себе многофилиальную компанию (например торговую сеть) да еще ведущую многовалютный учет с использованием 7-12 аналитик (разрезы по валюте, по филиалу, по отделам, регионам, товарам, группам товаров, ... ) если нужно ввести исправление (а стороно не подходит) да еще если компания имеет аффилированых лиц кучу, которые сами в свою очередь имееют клиентов а нам нужен агрегированный баланс, причем некоторые из аффилированных лиц например оффшорные компании, причем зарубежные со своими планами счетов. Это уже не бухучет. Подобные системы нужны поскольку бух. и налоговый учет (кстати понятия тоже разные) настолько убоги (и не надо прибавлять что у нас в стране. В GAAP еще все более размыто. Наш бухучет более формален ИМХО)что не могут отражать реальное положение дел. Если бы просто нужно было сделать бух систему то все было бы проще. А в разветвленной системе в случае отката ручками все не перебъешь... :(. Кстати зря так насчет алгоритмов. Алгоритм и вправду получается интересный. Т.е. превичные документы в случае изменения их задним числом порождают целую цепную реакцию изменений. Тут ксати явно пахнет математической теорией. Интересно же!!!


:super:

Здравствуйте Tiger, Вы писали:

T>Здравствуйте VladD2, Вы писали:

VD>>Мужик! Вся страна уже восемь лет так работает. И без твоих алгоритмов, а ты только проснулся.
T>Да нет, я имел ввиду автоматизацию процесса...

VD>>Если на базе базы . Посчитан и сддан баланс, то менять ничего нельзя. Это я тебе говорю как практик сдававший балансы, а потом матерясь искал, что я там наизменял задним числом. Не мелочь разную (аналитику, коментании и т.п.) менять конечно можно, но радости от этого никакой. А если ты баланс не сдал, то меняй что хош. Нужно знаьб кто что менял? Ну, дык создай таблицу в которой лог изменений записываться будет (как в твоем любимом MSSQL7). А пересчитывать в соверменной системе (созданной на современный средствах) ничего не нужно. Просто забудь о спец таблицах с закешированными расчетами. Как при этом жить? А выбрасить нахрен MSSQL7 и поставить MSSQL2k или Оракл. В них есть индексированные/материализованные view, которые пересчитываются автоматом (и очень быстро).

T>Но я же писал об УЧЕТНЫХ системе а не о бухгалтерской. Сейчас рулит понятие управленческого учета когда хозяева компаний хотят видеть реальное положение вещей в компании. То что когда сдан в налоговую баланс и в этом периоде изменять ничего нельзя это как бы очевидно. Но вот например представим себе многофилиальную компанию (например торговую сеть) да еще ведущую многовалютный учет с использованием 7-12 аналитик (разрезы по валюте, по филиалу, по отделам, регионам, товарам, группам товаров, ... ) если нужно ввести исправление (а стороно не подходит) да еще если компания имеет аффилированых лиц кучу, которые сами в свою очередь имееют клиентов а нам нужен агрегированный баланс, причем некоторые из аффилированных лиц например оффшорные компании, причем зарубежные со своими планами счетов. Это уже не бухучет. Подобные системы нужны поскольку бух. и налоговый учет (кстати понятия тоже разные) настолько убоги (и не надо прибавлять что у нас в стране. В GAAP еще все более размыто. Наш бухучет более формален ИМХО)что не могут отражать реальное положение дел. Если бы просто нужно было сделать бух систему то все было бы проще. А в разветвленной системе в случае отката ручками все не перебъешь... . Кстати зря так насчет алгоритмов. Алгоритм и вправду получается интересный. Т.е. превичные документы в случае изменения их задним числом порождают целую цепную реакцию изменений. Тут ксати явно пахнет математической теорией. Интересно же!!!


T>
Это уже интереснее. Обработка откатов, по-моему, вообще одна из самых интересных проблем автоматизации бизнеса. Обычна ситуация, когда некий документ "вводится" в систему числом различной степени задности.
Вообще говоря, состояние счетов однозначно определяется историей проводок. Тонкость в том, что сами проводки, вообще говоря, зависят от состояния счетов на момент проведения операции. Напрашивается такое решение:
1. Хранить журнал операций в дополнение к журналу проводок. То есть, мы всегда можем убить список проводок и "запустить" этот журнал на выполнение, и он нам все восстановит. В широком смысле этот журнал — это последовательность тех действий, которые выполняли операторы системы.
2. Когда нам надо провести некое исправление, мы откатываем журнал проводок до даты Т, модифицируем журнал операций на дату Т, проводим его от даты Т до сегодняшнего дня. Громоздко, но надежно. Итак, rollback-correct-rollforward.
Проблемы — огромные затраты на проведение исправлений. Они растут в лучшем случае линейно от "степени задности числа".
С другой стороны, исправления задним числом все равно надо считать исключением. Бизнес, построенный только на них, неэффективен. В первую очередь потому, что задержка проведения документов в среднем на Т приводит к неопределенности состояния бизнеса. То есть, если у нас типичный срок внесения исправлений — две недели, то какие бы то ни было отчеты будут иметь смысл только при условии, что они показывают состояние двухнедельной и более давности.
Поэтому надо подходить с двух концов:
1. Оптимизация rb-cr-rf процесса: разделять независимые операции и откатывать только те, на которые могло повлиять проводимое исправление.
2. Оптимизация бизнес-процесса. Если у вас экспедиторы не сдают накладные по неделе — дайте им по нотебуку с модемом, чтобы они отчитывались в реальном времени. Поставьте на склад систему считывания штрихкодов. Сделайте кассу цифровой. Это облегчит жизнь не только программистам, но всему управляющему персоналу.

Здравствуйте Sinclair, Вы писали:

S>Это уже интереснее. Обработка откатов, по-моему, вообще одна из самых интересных проблем автоматизации бизнеса. Обычна ситуация, когда некий документ "вводится" в систему числом различной степени задности.
S>Вообще говоря, состояние счетов однозначно определяется историей проводок. Тонкость в том, что сами проводки, вообще говоря, зависят от состояния счетов на момент проведения операции.
Напрашивается такое решение:
S>1. Хранить журнал операций в дополнение к журналу проводок. То есть, мы всегда можем убить список проводок и "запустить" этот журнал на выполнение, и он нам все восстановит. В широком смысле этот журнал — это последовательность тех действий, которые выполняли операторы системы.

S>2. Когда нам надо провести некое исправление, мы откатываем журнал проводок до даты Т, модифицируем журнал операций на дату Т, проводим его от даты Т до сегодняшнего дня. Громоздко, но надежно. Итак, rollback-correct-rollforward.
S>Проблемы — огромные затраты на проведение исправлений. Они растут в лучшем случае линейно от "степени задности числа".
Проблемы еще более общирны: что делать если проводки после даты Т не укладываются после добавления новой проводки N.
Например было на складе 6 единиц. В поле даты Т все 6 единиц ушли со склада.
Мы добавляем проводку N: ушла еще одна единица.
При "укладовании" проводок обратно непонятно где взять 6 единиц, когда их на складе 5 осталось?.
Результат:
1. посылаем в.. все проводки поле даты Т
2. полным перебором пытаемся уложить оставшиеся проводки
3. посылаем в.. юзера с идеей проводки N
4.

S>С другой стороны, исправления задним числом все равно надо считать исключением. Бизнес, построенный только на них, неэффективен.
S>2. Оптимизация бизнес-процесса. Если у вас экспедиторы не сдают накладные по неделе — дайте им по нотебуку с модемом, чтобы они отчитывались в реальном времени.
Даешь каждой доярке по ноуту!

Здравствуйте Sinclair, Вы писали:

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

Не... Лучше экспидитору по голове дать или по карману, а с ноутбук лучше дать кому нибудь другому.

S>Проблемы еще более общирны: что делать если проводки после даты Т не укладываются после добавления новой проводки N.
S>Например было на складе 6 единиц. В поле даты Т все 6 единиц ушли со склада.
S>Мы добавляем проводку N: ушла еще одна единица.
S>При "укладовании" проводок обратно непонятно где взять 6 единиц, когда их на складе 5 осталось?.
S>Результат:
S>1. посылаем в.. все проводки поле даты Т
S>2. полным перебором пытаемся уложить оставшиеся проводки
S>3. посылаем в.. юзера с идеей проводки N
S>4.
1. Светик, мысли реально Ну откуда у тебя возьмется накладных на 6 единиц??? Склад же не может выдавать товары в минус.
2. Если это не склад, а некая другая сущность, типа счета в бухгалтерии, то у нас получается перерасход. Т.е. система не должна была позволить провести какие-то документы, а она позволила. Вполне реальная ситуация.
Итак, теперь мы имеем а) одно "правильное" действие(которое было потеряно) , и N "неправильных". Вообще говоря, в этом случае мы отменяем отмену с соответствующим результатом. Вариант — попытаться игнорировать недопустимую операцию и продолжать все остальные. Я бы реализовывал так: пытаться роллфорвардить все действия, писать ошибки в лог, если весь журнал прошел успешно, то делать коммит, иначе отменять отмену. Затем ответственный человек думает, как разрулить экстремальные ситуации. Это как раз и есть то, чем занимаются бухгалтера — у меня мама работала главбухом, и основное время съедало последовательное перебалансирование счетов из-за всяких мудаков, которые в зднем кармане документы по месяцу носят. Это решение — всего лишь автоматизация бизнесс-процесса.

S>>С другой стороны, исправления задним числом все равно надо считать исключением. Бизнес, построенный только на них, неэффективен.
S>>2. Оптимизация бизнес-процесса. Если у вас экспедиторы не сдают накладные по неделе — дайте им по нотебуку с модемом, чтобы они отчитывались в реальном времени.
S>Даешь каждой доярке по ноуту!.

Здравствуйте VladD2, Вы писали:

VD>Здравствуйте Sinclair, Вы писали:

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

VD>Не... Лучше экспидитору по голове дать или по карману, а с ноутбук лучше дать кому нибудь другому.
Нет, если у тебя машина идет в рейс ко Золотому Кольцу на две недели, то ты по голове хоть задавайся.
Между прочим, был я в одном магазинчике фирмы Найки (Nike), в маленьком городке Lancaster, PA. Так вот там у продавцов наушнички с микрофоном подключенные к портативной радиостанции. Зачем? А чтоб не орать "Клава, сорок третий синие есть?" на весь магазин. А хождение туды-сюды по такому залу может съесть половину времени продавца, которое он мог бы потратить на клиента. И если бедному экспедитору приходится переться в бухгалтерию, которая за 500м от склада, только для сдачи бумажек, то он и будет это раз в неделю делать. Потому что это лишние полчаса, а за это время можно еще в один магазин успеть заехать.
Вообще, ясен пень, это все надо считать. То есть брать предприятие, строить модель бизнеса, смотреть потери, затраты на разработку и внедрение, ожидаемую экономию, время окупаемости. Нету универсальных решений. Иначе бы ребята из Артур Андерсена меньше нас, программеров, получали бы.
Я просто исхлжу в своих рекомендациях из того, что предприятие уже достаточно созрело для применения системы автоматизации. И типичная ошибка, которую делают такие предприятия — это забыть про ввод данных в систему. Если не делать его удобным, надежным, и быстрым — то никакие суперумные алгоритмы ничем не помогут, т.к. узким местом останется проверка соответствия данных реальности. Вот в параллели я ответил насчет склада — вообще косяки, когда внезапно обнаруживается документ, с учетом которого суммарная выдача товара со склада превышает его запас, очень часто являются плодом вот такой фигни:
Приходит на склад экспедитор с накладной на 500 банок варенья. 5 видов, по 100 банок каждого вида. А грузчикам смотреть в дно коробки лень, да и читать по-импортному они не умеют, вот они и грузят че под руку подвернется. Магазин при получении товара плюется, но подписывает — ладно, хрен с ним, все едино стоит все одинаково. В следующем заказе ассортимент добъем. И вот пока экспедитор бумажку вернет, со склада еще отгружают то, что было. Потом мы и обнаруживаем, что сливового варенья удалось отгрузить 300 банок, а его всего 200 было. Это потому, что на самом деле мы отгрузили 200 вишневого, а у нас его 100 записано. Это я не придумываю, это я сам видел. Делали мы систему автоматизации.
Вот поставить штрих-сканер на склад, и мужика к нему, который получает в 10 раз меньше чем главбух, к коробкам его подносить — и нет проблемы.

Здравствуйте Sinclair, Вы писали:

S>>Проблемы еще более общирны: что делать если проводки после даты Т не укладываются после добавления новой проводки N.
S>>Например было на складе 6 единиц. В поле даты Т все 6 единиц ушли со склада.
S>>Мы добавляем проводку N: ушла еще одна единица.
S>>При "укладовании" проводок обратно непонятно где взять 6 единиц, когда их на складе 5 осталось?.
S>>Результат:
S>>1. посылаем в.. все проводки поле даты Т
S>>2. полным перебором пытаемся уложить оставшиеся проводки
S>>3. посылаем в.. юзера с идеей проводки N
S>>4. ;)
S>1. Светик, мысли реально :) Ну откуда у тебя возьмется накладных на 6 единиц??? Склад же не может выдавать товары в минус.
Например, еще одной накладной нехватает на приход 1 штуки на склад :)

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

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

S>Вообще говоря, в этом случае мы отменяем отмену с соответствующим результатом. Вариант — попытаться игнорировать недопустимую операцию и продолжать все остальные. Я бы реализовывал так: пытаться роллфорвардить
(прости безграмотность, это что?)
S>все действия, писать ошибки в лог, если весь журнал прошел успешно, то делать коммит, иначе отменять отмену. Затем ответственный человек думает, как разрулить экстремальные ситуации. Это как раз и есть то, чем занимаются бухгалтера — у меня мама работала главбухом, и основное время съедало последовательное перебалансирование счетов из-за всяких мудаков, которые в зднем кармане документы по месяцу носят. Это решение — всего лишь автоматизация бизнесс-процесса.
Пахнет бесконечностью.
Мне кажется, что сдесь требуется аггоритм который выявляет скрытые острые места, как то перерасход, непарвильная последовательность и др. нелогичности. Каждое подозрительное место "исправляется" с использованем заглушек (специальных мест для недостающих, по нашему мнению, документов). Так пытаемся уложить все оставшиеся проводки. В следующий раз при внесении изменений пытаемся избавиться от заглушек или расставить их по-новому.

Здравствуйте Sinclair, Вы писали:
S>Приходит на склад экспедитор с накладной на 500 банок варенья. 5 видов, по 100 банок каждого вида. А грузчикам смотреть в дно коробки лень, да и читать по-импортному они не умеют, вот они и грузят че под руку подвернется. Магазин при получении товара плюется, но подписывает — ладно, хрен с ним, все едино стоит все одинаково. В следующем заказе ассортимент добъем. И вот пока экспедитор бумажку вернет, со склада еще отгружают то, что было. Потом мы и обнаруживаем, что сливового варенья удалось отгрузить 300 банок, а его всего 200 было. Это потому, что на самом деле мы отгрузили 200 вишневого, а у нас его 100 записано. Это я не придумываю, это я сам видел. Делали мы систему автоматизации.
за такое увольняют, по нормативным документам:
клпдовщик ОБЯЗАН поЩитать, если колличство не совподает, обе стороны пишут новое и стявят подписи и ... нет пересортицы
S>Вот поставить штрих-сканер на склад, и мужика к нему, который получает в 10 раз меньше чем главбух, к коробкам его подносить — и нет проблемы.

Здравствуйте Sinclair, Вы писали:

S>Между прочим, был я в одном магазинчике фирмы Найки (Nike), в маленьком городке Lancaster, PA. Так вот там у продавцов наушнички с микрофоном подключенные к портативной радиостанции. Зачем? А чтоб не орать "Клава, сорок третий синие есть?" на весь магазин.
Как вариант: чтобы следить за вежливостью продавцов и на основе записей разбирать ошибки и делать тренинги?
Капиталисты это любят

S>Вот поставить штрих-сканер на склад, и мужика к нему, который получает в 10 раз меньше чем главбух, к коробкам его подносить — и нет проблемы.
Модель б/у матиматически строгая, если учитывать все рекомендации получаетсся достаточна стройная система. Неидеальны в этом поцессе люди и, как следствие, предприятие также хаотично.

Техника (сканеры, кассы...) может уменьшить трудозатраты, но не идеализировать поведение людей до нужной степени.

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

Следовательно надо строить систему, которая позволяла бы вводить данные с разной степенью достоверности, т.е. у всех объектов/данных этой ситемы есть атрибут достоверности.
Как минимум, сиситема должна принимать первичку (как данные так и документы) и строить отчеты.

В нашем случае отчетность — это два мощьных алгоритма:
1. для потсоение отчетов различной степени достоверности
2. для строгой отчетности перед налоговой (алгоритм временно перебалансирует счета, учтет достоверность и выдаст строгий отчет).

Таким образом мы решаем:
1. задачу управленческого учета: постоение отчетов различной степени достоверности но всегда по текущим данным.
2. задачу "Как плотить налоги в четко заданном отрезке?".

Здравствуйте Sinclair, Вы писали:

VD>>Не... Лучше экспидитору по голове дать или по карману, а с ноутбук лучше дать кому нибудь другому.
S>Нет, если у тебя машина идет в рейс ко Золотому Кольцу на две недели, то ты по голове...

Ну, у каждого свои методы...

PS

Вообще — это была "шутка юмора" (с).