powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Форумы / Разработка информационных систем [игнор отключен] [закрыт для гостей] / Схемы построения учетной системы. Нужна критика.
25 сообщений из 79, страница 2 из 4
Схемы построения учетной системы. Нужна критика.
    #34967839
Lunx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Присоединюсь к топику следующей мыслью. Есть поля документа, которые после "проведения/утверждения/постирования/изменения статуса" можно поменять, есть которые нельзя. Best practice говорит, что удалять физически документ с проводками не стоит. Мысль разносить по разным таблицам разные части учета (бух, налоговый, оперативный) - весьма плодотварна, Еще отдельно несите дебиторов, кредиторов, банк, основные средства, признаки и объекты управленческого учета. Смотрите как устроен SAP = мудрость (после 1С)
...
Рейтинг: 0 / 0
Схемы построения учетной системы. Нужна критика.
    #34967883
Фотография Сергей Васкецов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LunxСмотрите как устроен SAP = мудрость (после 1С)
Весьма бездарно SAP устроен, не надо ля-ля.
...
Рейтинг: 0 / 0
Схемы построения учетной системы. Нужна критика.
    #34967914
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
sergey888

Вообще в бухгалтерии нет "отката" проводки. Делается сторнирующая проводка.

А в оперативном учете есть :-) и что делать?
...
Рейтинг: 0 / 0
Схемы построения учетной системы. Нужна критика.
    #34967917
Фотография niki4550148
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сергей Васкецов LunxСмотрите как устроен SAP = мудрость (после 1С)
Весьма бездарно SAP устроен, не надо ля-ля.

По теме двух веток у меня зародилась мысль что сергей все таки разработал идеальную систему... Я прямо таки жду презентации - скоро закроются мягкие и сапы - это ли не план Путина!!!
...
Рейтинг: 0 / 0
Схемы построения учетной системы. Нужна критика.
    #34967928
Фотография niki4550148
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
простите за оффтопик - накипело!!!
...
Рейтинг: 0 / 0
Схемы построения учетной системы. Нужна критика.
    #34968110
Фотография Сергей Васкецов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
niki4550148По теме двух веток у меня зародилась мысль что сергей все таки разработал идеальную систему
В части, обсуждаемой в топике, ее можно улучшить не намного. Про идеальность я не утверждал. Ошибки в известных системах есть и повторять их у себя причин не вижу.

На всякий случай комментарии "саперу" и Вам тоже.

LunxBest practice говорит, что удалять физически документ с проводками не стоит.
Здравая логика говорит, что возможность или невозможность удаления документа никак не связана с наличием или отсутствием у него проводок, а определяется исключительно статусом документа (ну и полномочиями пользователя).

LunxМысль разносить по разным таблицам разные части учета (бух, налоговый, оперативный) - весьма плодотварна
Она бесконечно бредова по сути. Что Вы будете делать при добавлении еще 5-10 видов учета?

LunxЕще отдельно несите дебиторов, кредиторов, банк
Куда "нести"? Если разнести отдельно - тоже спорная тема, на пустом месте придумать себе задачу сопоставления дебиторов и кредиторов и доблестно ее решать. У меня одно и то же предприятие может быть и дебитором, и кредитором, и банком (реквизиты его вводятся один раз в одном месте, для непонятливых), все взаиморасчеты выполняются как 2 пальца.
...
Рейтинг: 0 / 0
Схемы построения учетной системы. Нужна критика.
    #34968116
Фотография Сергей Васкецов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ivan Durak sergey888Вообще в бухгалтерии нет "отката" проводки. Делается сторнирующая проводка. А в оперативном учете есть :-)
В ОУ даже сложно придумать корректное обоснование необходимости формирования проводок. А уже об их откате и говорить не приходится.
...
Рейтинг: 0 / 0
Схемы построения учетной системы. Нужна критика.
    #34968144
sergey888
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ivan Durak sergey888

Вообще в бухгалтерии нет "отката" проводки. Делается сторнирующая проводка.

А в оперативном учете есть :-) и что делать?

Пример в студию. Вариант с ошибкой оператора не предлагать!
...
Рейтинг: 0 / 0
Схемы построения учетной системы. Нужна критика.
    #34968201
PiterBest
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Сергей Васкецов

[quot Lunx]Мысль разносить по разным таблицам разные части учета (бух, налоговый, оперативный) - весьма плодотварна
Она бесконечно бредова по сути. Что Вы будете делать при добавлении еще 5-10 видов учета?

А Вы хотите сказать что по видам учета разделять не надо ?
Даже если Вы и придумаете еще 10 видов учета - это наоборот удобно.
...
Рейтинг: 0 / 0
Схемы построения учетной системы. Нужна критика.
    #34968218
Фотография Сергей Васкецов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PiterBest Сергей Васкецов
[quot Lunx]Мысль разносить по разным таблицам разные части учета (бух, налоговый, оперативный) - весьма плодотварна
Она бесконечно бредова по сути. Что Вы будете делать при добавлении еще 5-10 видов учета?
А Вы хотите сказать что по видам учета разделять не надо ?
Я хочу сказать, что не надо разносить по разным таблицам .

PiterBestДаже если Вы и придумаете еще 10 видов учета - это наоборот удобно.
То есть, добавлять новые таблицы, изменять логику работы системы и писать новые отчеты при добавлении нового учета - это "удобно"?
...
Рейтинг: 0 / 0
Схемы построения учетной системы. Нужна критика.
    #34968302
Lunx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Необходимость организации ведения разных таблиц для разных видов учета продиктова требованем к скорости обработки данных. Как пример - дебиторская задолженность. В SAP погашение задолженности например пишется в главную книгу общей суммой, а в книгу дебиторов - с выравниванием по открытым позициям. Для чего это надо. При составлении баланса (главная книга) нужны данные только по обороту, сальдо счета, информация по каждой отдельной позиции - лишняя. При составлении же акта взаиморасчетов - без нее никак. Выражается это в том, что у нас есть SELECT на разные таблицы, в зависимости от контекста и условие стоит не счет=выбранный счет когда Вы все пишите в главную книгу, где счетов мильен, а дебитор=выбранный дебитор где дибиторов - ну сколько бедиторов у компании. Желание свалить все в кучу говорит о том, что человек не занимается оптимизацией скорости выборок. На Ваш вопрос - если поялвяется еще 10 видов учета - да, надо делать 10 новых таблиц и писать функционал на них. Как пример - учет дебиторской задолженности в 1С - один регистр - сводный по суммам, второй по открытым позициям, срокам платежа. В этом смысле 1С растет (причем старается в сторону SAP, вроде).
...
Рейтинг: 0 / 0
Схемы построения учетной системы. Нужна критика.
    #34968330
Фотография Сергей Васкецов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LunxНа Ваш вопрос - если поялвяется еще 10 видов учета - да, надо делать 10 новых таблиц и писать функционал на них. Как пример - учет дебиторской задолженности в 1С - один регистр - сводный по суммам, второй по открытым позициям, срокам платежа. В этом смысле 1С растет (причем старается в сторону SAP, вроде).
Дальнейшее обучение индивидуумов, искалеченных SAP-ом и 1С-ом, буду проводить за деньги.
...
Рейтинг: 0 / 0
Схемы построения учетной системы. Нужна критика.
    #34968402
strizh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
To Бизон:
>Вы предлагаете по сути разделит на две базы. Основная рабочая и архивная?
Нет :) Посмотрите, как устроены нормальные базы данных (MS, Oracle, Postgres). Таблицы создаются не просто в базе данных, а в одной из схем базы. Зачем схемы - читайте умные книги и пр. Например, для приема, о котором я говорил выше.

Насчет проведения.
PostgreSQL.
В таблице ТаблицаДокументов есть колонка REGISTERED - флажок проведен-нет и колонка ID.
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
create or replace function СоздатьПроводкиПоДокументу(integer) returns trigger as '
   declare iDocID alias for $1;
begin
   -- Действия по вставке нужных проводок по документу
   ...
end'
language 'plpgsql';

create or replace function УдалитьПроводкиПоДокументу(integer) returns trigger as '
   declare iDocID alias for $1;
begin
   delete from Проводки where ДокументИсточник = iDocID;
end'
language 'plpgsql';

create or replace function ДоИзмененияДокумента() returns trigger as '
  declare bDelete bool := false; bInsert bool := false; bAllowed bool := true;
begin
   -- по операции и флажку REGISTERED найдем, можно ли удалять-изменять
   -- и проводить-отменять проведение
   if TG_OP = ''DELETE'' then
      bAllowed := (case when old.REGISTERED then false else true end);
   elsif TG_OP = ''UPDATE'' then
      bAllowed := (case when old.REGISTERED then false else true end);
      bDelete := (case when old.REGISTERED and not new.REGISTERED then true else false end);
      bInsert := (case when new.REGISTERED and not old.REGISTERED then true else false end);
   elsif TG_OP = ''INSERT'' then
      bInsert := (case when new.REGISTERED then true else false end);
   end if;
   if not bAllowed then
      -- операция с проведенным документом запрещена - исключение
      raise exception ''Операция с проведенным документом запрещена !'';
      return null;
   else
      if bDelete then
         select ОтменитьПроводкиПоДокументу(old.ID);
      end if;
      if bInsert then
         select СоздатьПроводкиПоДокументу(new.ID);
      end if;
   end if;
   if TG_OP = ''DELETE'' then
      return old;
   else
      return new;
   end if;
end'
language 'plpgsql';

create trigger ДоИзмененияДокумента before update or insert or delete on ТаблицаДокументов
  for each row execute procedure ДоИзмененияДокумента();

И что тут обсуждать ?
Один триггер и 3 функции ?
Посему совет Бизону - сначала изучите базовые возможности выбранной Вами СУБД,
а потом двигайтесь к цели. А если будете логику на клиенте делать - получите еще одну 1С, только хуже !
...
Рейтинг: 0 / 0
Схемы построения учетной системы. Нужна критика.
    #34968567
Бизон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Если я правильно понял предложенный Вами механизм. Вы предлагаете использовать только одно состояние документа и после его утверждения не менять. Все дальнейшие операции проводить только сторнированием? А как быть например, есть приходная накладная мы приняли товар. Записали. Провели. Через день приходить ее замена ошиблись с ценой.
...
Рейтинг: 0 / 0
Схемы построения учетной системы. Нужна критика.
    #34968671
Фотография Сергей Васкецов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
БизонА как быть например, есть приходная накладная мы приняли товар. Записали. Провели. Через день приходить ее замена ошиблись с ценой.
1. Что значит "провели"? Если говорить о бухучете, то никто не мешает проверять и утверждать проводки в конце учетного периода, а не в онлайне.
2. Что мешает разутвердить документ, исправить его и утвердить заново?
...
Рейтинг: 0 / 0
Схемы построения учетной системы. Нужна критика.
    #34968706
Lunx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сергей Васкецов БизонА как быть например, есть приходная накладная мы приняли товар. Записали. Провели. Через день приходить ее замена ошиблись с ценой.
1. Что значит "провели"? Если говорить о бухучете, то никто не мешает проверять и утверждать проводки в конце учетного периода, а не в онлайне.
2. Что мешает разутвердить документ, исправить его и утвердить заново?

Чухня. Мешает принцип - согласно которому проведенный документ можно только сторнировать, а не исправлять задним числом.
...
Рейтинг: 0 / 0
Схемы построения учетной системы. Нужна критика.
    #34968721
sergey888
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
БизонЕсли я правильно понял предложенный Вами механизм. Вы предлагаете использовать только одно состояние документа и после его утверждения не менять. Все дальнейшие операции проводить только сторнированием? А как быть например, есть приходная накладная мы приняли товар. Записали. Провели. Через день приходить ее замена ошиблись с ценой.

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

В когда в магазине товар покупаете, то сразу его оплачиваете. Даже если продавец ошибся с ценой, то он не придет к Вам домой чтобы вернуть то, что вы переплатили.
...
Рейтинг: 0 / 0
Схемы построения учетной системы. Нужна критика.
    #34968722
Фотография Сергей Васкецов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LunxМешает принцип - согласно которому проведенный документ можно только сторнировать, а не исправлять задним числом.
Ну и в топку этот принцип, если он жить мешает. Если система не умеет корректно проводить изменения задним (передним :)) числом - в топку эту систему.
...
Рейтинг: 0 / 0
Схемы построения учетной системы. Нужна критика.
    #34968795
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Бизон
скромное предложение...возьмите за основу самую распространенную практику (см. рис)
- надежно
- практически безразмерно для расширения
- просто в реализации

Основные правила, вкратце:
- данные учета - таблица(ы) фактов с необходимыми для целей учета и отчетности измерениями.
- вся отчетность формируется только по данным учета, забудьте на время что есть какие-то документы и прочие источники данных
- документ = источник данных, регистратор событий, фактов
- Процедура учета выполняет конвертацию данных документа (или другого источника данных) в структуру данных учета (учетного регистра если нравится)
- учет может быть многоуровневый, т.е. учет одного документа формирует таблицу фактов №1, если учет выполнен, на основании учтенных данных может формироваться таблица фактов №2 и т.д.
- учет может быть многоплановый, т.е. один и тот же документ может быть отражен параллельно в более чем одной таблице фактов.
- Учтенный документ недоступен для изменения, чтобы изменить документ необходимо отменить его учет
- Процедура отмены учета отслеживает возможность внесения изменений

Появляются новые документы или требуются новые структуры фактов - внесение изменений довольно простая процедура, не требующая останова.
По поводу того, удалять или помечать записи учета как недействительные - как нравится. Если не нужно хранить историю - удаляйте, нужно - помечайте.
...
Рейтинг: 0 / 0
Схемы построения учетной системы. Нужна критика.
    #34968857
sergey888
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сергей Васкецов LunxМешает принцип - согласно которому проведенный документ можно только сторнировать, а не исправлять задним числом.
Ну и в топку этот принцип, если он жить мешает. Если система не умеет корректно проводить изменения задним (передним :)) числом - в топку эту систему.

А разве сторнирование не является исправлением ошибки?
...
Рейтинг: 0 / 0
Схемы построения учетной системы. Нужна критика.
    #34968873
Бизон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
sergey888 БизонЕсли я правильно понял предложенный Вами механизм. Вы предлагаете использовать только одно состояние документа и после его утверждения не менять. Все дальнейшие операции проводить только сторнированием? А как быть например, есть приходная накладная мы приняли товар. Записали. Провели. Через день приходить ее замена ошиблись с ценой.

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

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

Не проплатили. А если наоборот он осталься должен.
...
Рейтинг: 0 / 0
Схемы построения учетной системы. Нужна критика.
    #34968922
Фотография Сергей Васкецов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
sergey888А разве сторнирование не является исправлением ошибки?
:) Методов исправления ошибок много, например, сделать с нуля новую БД и заново все ввести.

Сторнирование - это операция изменения чего-то, что менять напрямую нельзя, но очень хочется, она имеет свою дату, отличную от даты сторнируемой операции. Ограничивать сторнирование только лишь исправлением ошибок не стоит.
...
Рейтинг: 0 / 0
Схемы построения учетной системы. Нужна критика.
    #34968926
Фотография Сергей Васкецов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
БизонА если наоборот он осталься должен.
Разноска платежей вообще-то отдельная операция. И уж тем более в ней нечего делать складским документам.
...
Рейтинг: 0 / 0
Схемы построения учетной системы. Нужна критика.
    #34969000
Бизон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Предлагаю разобраться на примере конкретной операции. Сидит оператор на складе, ему принесли приходную накладную. Вводит. Нажимает кнопку «ОК». Указанное количество товара соответственно увеличивает остатки на складе товара. Сумма в накладной увеличивает наш долг поставщику. На следующий день поставщик нашел ошибку, не по той цене отгрузил. Присылает замену. А может только в конце месяца. На цену товара плевать всем. Никто ее не контролирует. Работа с поставщиком идет по договору, оплата в конце месяца.
...
Рейтинг: 0 / 0
Схемы построения учетной системы. Нужна критика.
    #34969056
Фотография Сергей Васкецов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
БизонСумма в накладной увеличивает наш долг поставщику
Ой ли? Я бы все же "плясал" от счета-фактуры.
...
Рейтинг: 0 / 0
25 сообщений из 79, страница 2 из 4
Форумы / Разработка информационных систем [игнор отключен] [закрыт для гостей] / Схемы построения учетной системы. Нужна критика.
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]