Нужна помощь спецов по автоматизации бухучета

[metaclass]

Как организовать расчет в случае, если есть документы покупки и документы оплаты, они закрывают друг друга(т.е. формируется связь m:n по мере поступления тех и других и по другим критериям из мозга бухгалтера), но есть необходимость учесть сторнирование документов?

Я что-то за 10 лет автоматизации бухучета этот вопрос теоретически правильно так и не решил - оставил на усмотрение бухгалтерам, чтобы они вручную разбирались.

Кстати тема "закрытие(оплата) одних документов другими" это такой специальный бухгалтерско-программистский фетиш, она выедает мозг просто феноменально.

Comments

[rssh.livejournal.com]

> Кстати тема "закрытие(оплата) одних документов другими" это такой специальный бухгалтерско-программистский фетиш, она выедает мозг просто феноменально.

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

[a-lourier.livejournal.com]

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

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

[theiced.livejournal.com]

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

1. я с бухгалтерией работать больше не буду.
2. когда мы таки начнём массовые расстрелы, бухгалтеры пойдут в первых рядах, сразу после перлистов.

[a20bostan.livejournal.com]

обратитесь к репетитору, который специализируется на бухучете, он вам все разъяснит - http://www.repetitors-moscow.ru/

Бухгалтерский бред.

[az-from-belarus.livejournal.com]

Если слишком идти на поводу у бухгалтеров, то рано или поздно будешь упираться в тот или иной бред.
Тут надобно пожестче быть. Если бухгалтершам предоставляются ПОЛНОМОЧИЯ по составлению или корректировке ТЗ, то они симметрично должны предполагать и ОБЯЗАННОСТИ, согласно которым в ТЗ все сущности и цепочки операций имели строгие, полные и непротиворечивые дефиниции. Не могут исполнить эти обязанности - браковать все их "требования" как невыполнимые и подрывающие создание/функционирование/развитие учетной системы.
Хорошим решением для таких случаев могло бы быть привлечение мозговитого думающиего консультанта-аудитора, способного выработать учетную политику и четко сформулировать соответствующие политике блоки требований к учетной системе. Бухгалтерам тогда останется лишь строго следовать заданной учетной политике и их нужно бить по голове и по кошельку за любые попытки ее нарушения.
А сторнирование документов - это бред. Сторно - это лишь бухгалтерская учетная операция, проводка. Документ - это более сложная сущность, уровня хозяйственных операций, а не учетных, учетные же операции, проводки лишь отслеживают в учете хозяйственные документы.

[gds.livejournal.com]

блядь, как же меня заебала эта хуйня на работе.
дали руками заводить -- вовремя не заводят, "времени нет", никаких актуальных данных в середине месяца нет, постоянно косяки в заведённых данных (которые заводят за пару дней до необходимости получения отчётов).
Сейчас пробуем автоматически -- в пределах периода имеем сальдо на начало (у каждой записи -- своя дата формирования; очевидно, в прошлом), имеем приходы и расходы (каждый из которых может быть как положителен, так и отрицателен). Дальше -- шаманские пляски. Сначала закрываем отрицательные суммы (возвраты продукции и возвраты денег) с соответствующими положительными из той же категории (приход/расход), в случае одинаковой даты. Затем взаимно закрываем положительные приходы с положительными расходами (рассматриваем приходы по возрастанию даты, пытаемся ими закрыть расходы (тоже, в свою очередь, по возрастанию даты)). Затем повторяем первый шаг, но не обращая внимания на даты.
Местечковые особенности состоят ещё в том, что закрытия идут в трёх валютах (учётная фиксирована, остальные -- с вариантами), и в зависимости от некоторых свойств расхода приоритет имеют разные приходы в разной степени.
Как-то так.
Так хуйня в том, что постоянно натыкаюсь на ошибки бухгалтерии в текущих данных, и это длится уже долго. И я ещё не приступал к курсовым/суммовым разницам.
Можно было бы спросить, не ебанулся ли я в процессе работы, эхехе. Но "на все вопросы рассмеюсь я тихо, на все вопросы не будет ответов" :]

[bogdanov-m.livejournal.com]

Не должны здесь счета закрываться оплатами.
Счет должен быть просто уведомлением клиенту, что он должен такую-то сумму. А клиент может недоплатить, переплатить, разбить платеж на части и черт знает что еще сделать.
То есть вот в этой вот PAYMENT_ON_ACCOUNT должен с одной стороны быть его накопленный долг без разбивки по счетам, а с другой стороны оплаты. Оплата с минусом - возврат.

[dragon-j.livejournal.com]

сама постановка мутная. вот и выедает мозг.
в чем проблема-то?
ведется учет в разрезе договоров? Ну и ведите. По оказанным услугам делайте начисления, генерируйте дебеторскую задолженность.
Дебеторская задолженность сворачивается с оплатами. Причем чтоб не страдать излишне, сворачивать рекомендуется по принципу FIFO, а не по бумажке счета (то есть платеж проводить к договору, если учет договорной, или к лицевому счету, если учет по лицевому счету, и закрывать платежом саму старую дебеторскую).
Получилась по каким-то причинам переплата? Ну будет у вас кредиторская задолженность по услугам (товарам)
Надо сделать корректировки в начислениях (вернуть 5 кубов воды.. хмм.. если вы за них со своей стороны кому-то платили могут быть нюансы, решаемые. ну да пусть просто тупо спишем у себя в потери) -- ну делайте. Уменьшайте начисления по конкретному договору (лицевому счету) и соответственно дебиторку (отрицательная дебиторка должна стать положительной кредиторкой :) на требуемую величину.
Возникла переплата после пересчета? Ну оставьте деньги до следующего периода, где начисление и новая дебиторка с ними свернется. Или сразу верните клиенту. Тогда сразу свернется.

Муть мне видится только в том, что учет хотят выстроить в разрезе договора/лицевого счета, а сторно проводят как-то в целом. Хотя должны проводить его точно так же с привязкой к договору/лицевому счету.