Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 62
Спасибо за статью.
Я, конечно не делал совсем сложных биллингов, но биллинги делал и вполне успешно, и вот какое у меня сложилось ощущение: схема перегружена.
Возможно стоит сделать сущность «счёт» в значении invoice (а уже в счёте куча invoice_items со своими свойствами типа цены, ставки НДС, закрытия позиции актами/фактурами и т.д, в этих же invoice_items учитывать скидки, items завязывать на services).
Пополнение баланса — счёт с соотв. отметкой. При этом естественно оплаты учитывать отдельно (у примеру, половина пришла в одной банковской транзакции, половина в другой или вообще налом/взаимозачётом)
Перевод средств между договорами — счёт с соотв. отметкой с двух сторон.
Любая коррекция баланса — только через txn и отметкой о новом балансе и сумме.
Соответственно к транзакции и вяжется что это за транзакция (к примеру, отмена прошлой транзакции)
Обороты можно считать из транзакций (предусмотреть отметку включать в обороты или нет)
Может я где-то и не прав, но в первом приближении мне это видится вот так
Я, конечно не делал совсем сложных биллингов, но биллинги делал и вполне успешно, и вот какое у меня сложилось ощущение: схема перегружена.
Возможно стоит сделать сущность «счёт» в значении invoice (а уже в счёте куча invoice_items со своими свойствами типа цены, ставки НДС, закрытия позиции актами/фактурами и т.д, в этих же invoice_items учитывать скидки, items завязывать на services).
Пополнение баланса — счёт с соотв. отметкой. При этом естественно оплаты учитывать отдельно (у примеру, половина пришла в одной банковской транзакции, половина в другой или вообще налом/взаимозачётом)
Перевод средств между договорами — счёт с соотв. отметкой с двух сторон.
Любая коррекция баланса — только через txn и отметкой о новом балансе и сумме.
Соответственно к транзакции и вяжется что это за транзакция (к примеру, отмена прошлой транзакции)
Обороты можно считать из транзакций (предусмотреть отметку включать в обороты или нет)
Может я где-то и не прав, но в первом приближении мне это видится вот так
Возможно стоит сделать сущность «счёт» в значении invoice (а уже в счёте куча invoice_items со своими свойствами типа цены, ставки НДС, закрытия позиции актами/фактурами и т.д, в этих же invoice_items учитывать скидки, items завязывать на services).
Так и сделано. В счёт входят проводки. Через тип проводки берется первичный документ, который и отображается в стчет.
Пополнение баланса — счёт с соотв. отметкой. При этом естественно оплаты учитывать отдельно (у примеру, половина пришла в одной банковской транзакции, половина в другой или вообще налом/взаимозачётом)
Счет это счет, а платеж это платеж. Не надо мешать разные сущности. Проводки не так просто добавлены.
Перевод средств между договорами — счёт с соотв. отметкой с двух сторон.
Любая коррекция баланса — только через txn и отметкой о новом балансе и сумме.
Соответственно к транзакции и вяжется что это за транзакция (к примеру, отмена прошлой транзакции)
Ага в итоге вы получаете мою же схему вид в профиль. Только без попыток уложить все документы в один счет.
Обороты можно считать из транзакций (предусмотреть отметку включать в обороты или нет)
Обороты и так считаются из транзакций это агрегативная таблица. Про пометку честно говоря не понял. Зачем это?
и вот какое у меня сложилось ощущение: схема перегружена.
Пока я вижу что вы пытались в счет положить все первичные документы. :)
Надо учитывать еще и стоимость поддержки всего этого.
Я сам очень люблю «реляционно-правильные» схемы, но как дело доходит до программирования начинается непропорциональный полезности рост трудозатрат с ростом количества технических таблиц…
> Счет это счет, а платеж это платеж. Не надо мешать разные сущности. Проводки не так просто добавлены.
Да, счет это счет, а платеж это платеж. Совершенно согласен. По счёту может быть и пять и десять платежей.
Я исхожу из того, что бизнес-взаимодействие идёт от счёта (или у вас ситуация не такая?).
Мне кажется, что по хорошему биллинг вообще не должен ничего знать про бухучёт. Бухгалтерии проще и удобнее работать с 1С, а пользователя биллинга со стороны клиента едва ли интересует что-то кроме непосредственно параметров услуг и закрывающих документов.
Как правильно заметили ниже, реализацию «российской специфики» проще делать как «интеграцию с 1с». Чаще всего смысл написания еще одной 1С неясен. Да и есть такая болезнь, что когда решают «1с нам не нужен, у нас всё в биллинге», приходится пилить расчёт зарплаты, отпускных, большичных и т.д., что пожирает ресурсы.
Я сам очень люблю «реляционно-правильные» схемы, но как дело доходит до программирования начинается непропорциональный полезности рост трудозатрат с ростом количества технических таблиц…
> Счет это счет, а платеж это платеж. Не надо мешать разные сущности. Проводки не так просто добавлены.
Да, счет это счет, а платеж это платеж. Совершенно согласен. По счёту может быть и пять и десять платежей.
Я исхожу из того, что бизнес-взаимодействие идёт от счёта (или у вас ситуация не такая?).
Мне кажется, что по хорошему биллинг вообще не должен ничего знать про бухучёт. Бухгалтерии проще и удобнее работать с 1С, а пользователя биллинга со стороны клиента едва ли интересует что-то кроме непосредственно параметров услуг и закрывающих документов.
Как правильно заметили ниже, реализацию «российской специфики» проще делать как «интеграцию с 1с». Чаще всего смысл написания еще одной 1С неясен. Да и есть такая болезнь, что когда решают «1с нам не нужен, у нас всё в биллинге», приходится пилить расчёт зарплаты, отпускных, большичных и т.д., что пожирает ресурсы.
Да, счет это счет, а платеж это платеж. Совершенно согласен. По счёту может быть и пять и десять платежей.
Что отображено через таблицу покрытия платежами.
Я исхожу из того, что бизнес-взаимодействие идёт от счёта (или у вас ситуация не такая?).
Вообще бизнес-взаимодействие идет от услуги. Счет это следствие или желания ее потребить или фактического ее потребления.
Мне кажется, что по хорошему биллинг вообще не должен ничего знать про бухучёт.
А тут и нет бухучета. В бухучете существенно больше сущностей. И да замечу, что к примеру проводки, левая правая сторона учета и т.п. обычный пользователь и не увидит. Единственное ухо которое может увидеть пользователь это остатки. Но тут есть хитрость. Эту часть будет видеть только тот пользователь, что у вас является бухгалтером и для него это понятные термины.
Как правильно заметили ниже, реализацию «российской специфики» проще делать как «интеграцию с 1с».
Еще раз задаю вопрос где тут «российская специфика» и vat и invoice внезапно есть не только в России.
Поддерживаю, мне тоже схема кажется слегка перегруженной. И очень завязанной на российский бухучет, а не на бизнес смысл. Если система будет использоваться только в России, то все ок, однако если в будущем планируется выход в другие страны, то тогда все будет очень печально.
И еще, для различных отчетов и аналитики можно не создавать специальные таблицы (типа bill.saldo), для этого прекрасно подходят materialized views.
И еще, для различных отчетов и аналитики можно не создавать специальные таблицы (типа bill.saldo), для этого прекрасно подходят materialized views.
Ребят принимается адекватная критика, а не ощущения.
Можно пояснить каким образом добавление документа НДС и одного поля для включения в начисление НДС стало привязкой к российскому бухучету? Тут как раз таки нет привязки. Если внезапно вам надо будет за рубежом продавать услуги с VAT ничего особо не поменяется, если без VAT ну тогда просто у вас bill.vat документов не будет и все.
Это зависит от возможностей РСУБД. К примеру PostgreSQL их поддерживает весьма ограничено, а MySQL не поддерживает совсем.
И очень завязанной на российский бухучет, а не на бизнес смысл. Если система будет использоваться только в России, то все ок, однако если в будущем планируется выход в другие страны, то тогда все будет очень печально.
Можно пояснить каким образом добавление документа НДС и одного поля для включения в начисление НДС стало привязкой к российскому бухучету? Тут как раз таки нет привязки. Если внезапно вам надо будет за рубежом продавать услуги с VAT ничего особо не поменяется, если без VAT ну тогда просто у вас bill.vat документов не будет и все.
И еще, для различных отчетов и аналитики можно не создавать специальные таблицы (типа bill.saldo), для этого прекрасно подходят materialized views.
Это зависит от возможностей РСУБД. К примеру PostgreSQL их поддерживает весьма ограничено, а MySQL не поддерживает совсем.
Забудьте про явное соответствие объект(сущность) — таблица. Все их нужно хранить в одном месте генерируя представление для БД. Иначе расширять такую структуру будет сложно и невозможно.
Вообще АСР — это абстракции, абстракции и еще раз абстракции. И много-много DSL.
Посмотрите хотя бы на 1С, не к ночи она будет помянута.
Вообще АСР — это абстракции, абстракции и еще раз абстракции. И много-много DSL.
Посмотрите хотя бы на 1С, не к ночи она будет помянута.
Забудьте про явное соответствие объект(сущность) — таблица. Все их нужно хранить в одном месте генерируя представление для БД.
У меня вполне четкая предметная область. Зачем мне это делать?
Вообще АСР — это абстракции, абстракции и еще раз абстракции. И много-много DSL.
Можно поинтересоваться сколько вы АСР написали и на какое количество клиентов они использовались?
Посмотрите хотя бы на 1С, не к ночи она будет помянута.
Поверьте я много что смотрел. В том числе и 1С.
Затем что все меняется быстрее, чем пишется код.
Сколько АСР я написал тут не имеет никакого значения.
Ну раз много что смотрели, то и сделали бы анализ. Вот такой подход, вот другой, вот критерии. Потом на основе анализа уже синтез под конкретное ТЗ, которое тоже надо выстрадать. Тогда я понимаю, будет статья. А пока маловато будет, маловато.
Сколько АСР я написал тут не имеет никакого значения.
Ну раз много что смотрели, то и сделали бы анализ. Вот такой подход, вот другой, вот критерии. Потом на основе анализа уже синтез под конкретное ТЗ, которое тоже надо выстрадать. Тогда я понимаю, будет статья. А пока маловато будет, маловато.
Затем что все меняется быстрее, чем пишется код.
В таком случае и ваш подход не работает и все тщетно :) Фактически же меняется не так уж и быстро. Эта схема результат опыта моей работы с различными АСР в течении 8 лет.
Сколько АСР я написал тут не имеет никакого значения.
Увы имеет, так-как иначе вы просто не знаете что из себя представляет пердметная область.
Ну раз много что смотрели, то и сделали бы анализ. Вот такой подход, вот другой, вот критерии. Потом на основе анализа уже синтез под конкретное ТЗ, которое тоже надо выстрадать. Тогда я понимаю, будет статья. А пока маловато будет, маловато.
Я не научную работу или диплом все же пишу. Я предлагаю один из вариантов решения. Использовать или нет это уже каждый решает сам.
Почему Вы считаете, что это типовая схема?
Очень круто. Теперь бы это в виде классов / схемы данных где-нибудь выложить + прикрутить генерацию счетов/актов — цены бы не было!
Спасибо, полезная статья.
Но я бы таки за основу брал двойную запись.
Она дает значительную гибкость.
Проводка она не даром двойная. Это дает очень большую гибкость.
Наличие баланса позволяет легко проверить/восстановить целостность.
Целостность движения денег дает множество дополнительных управленческих отчетов.
Делаем из этого биллинга биллинг торговли. Слишком большие изменения выходят. Склады, закупочные цены…
Делаем биллинг ресторана. С себестоимостями и т.п., ведь надо и калькуляции и склад…
И нет, это не бухгалтерия. Нам ведь нужно управлять скидками? А значит нужна себестоимость. Хоть какая.
ABC-отчет нужен?
А если нам нужно делать еще один налог. Типа налог с продаж. Похож на НДС, но помимо НДС и с другой логикой?
Вообще идея о том, чтобы учитывать отдельно проводки, а отдельно двигающие их документы логична. Но стоит довести ее до большей универсальности.
План счетов может быть абсолютно любой, а субсчета прекрасно привязываются к «договорам».
Тогда мы можем настроить систему так, чтобы было просто вести аналитику по рекламным компаниям (двигаем счета «скидка по рекламе А» и «расходы на рекламу А», можно с субсчетами по признаку «старый клиент/новый клиент»)
Маркетинговые ходы, где часть позиций продаются ниже себистоимости нужно очень тонко считать…
Мы арендуем от 8 до 12 серверов, в зависимости от загрузки по клиентам. Стоит ли взять 10 серверов по цене 9, и докупать мощности при необходимости уже не от 0 до 4, а от 0 до 2, при этом изредка имея простой одного сервера? Какую часть «доходов будущих периодов», т.е. предоплаты клиентов мы можем безболезненно потратить, зная что такое-то время они нам не понадобятся?
Все эти вопросы можно предусмотреть в гибком плане счетов. При этом бухгалтерия не совсем подходит для такого, ведь это чисто управленческий учет.
План счетов, субсчета, двойные проводки и универсальные ИД документов двигающих биллинг (например GUID + тип документа, и уже у каждого документа своя отдельная таблица, которую мы выбираем по типу документа, полученному по GUID). Абстрактный класс для документов, в реализации даем движение конкретных счетов… Ну а в остальном как у Вас…
Но я бы таки за основу брал двойную запись.
Она дает значительную гибкость.
Проводка она не даром двойная. Это дает очень большую гибкость.
Наличие баланса позволяет легко проверить/восстановить целостность.
Целостность движения денег дает множество дополнительных управленческих отчетов.
Делаем из этого биллинга биллинг торговли. Слишком большие изменения выходят. Склады, закупочные цены…
Делаем биллинг ресторана. С себестоимостями и т.п., ведь надо и калькуляции и склад…
И нет, это не бухгалтерия. Нам ведь нужно управлять скидками? А значит нужна себестоимость. Хоть какая.
ABC-отчет нужен?
А если нам нужно делать еще один налог. Типа налог с продаж. Похож на НДС, но помимо НДС и с другой логикой?
Вообще идея о том, чтобы учитывать отдельно проводки, а отдельно двигающие их документы логична. Но стоит довести ее до большей универсальности.
План счетов может быть абсолютно любой, а субсчета прекрасно привязываются к «договорам».
Тогда мы можем настроить систему так, чтобы было просто вести аналитику по рекламным компаниям (двигаем счета «скидка по рекламе А» и «расходы на рекламу А», можно с субсчетами по признаку «старый клиент/новый клиент»)
Маркетинговые ходы, где часть позиций продаются ниже себистоимости нужно очень тонко считать…
Мы арендуем от 8 до 12 серверов, в зависимости от загрузки по клиентам. Стоит ли взять 10 серверов по цене 9, и докупать мощности при необходимости уже не от 0 до 4, а от 0 до 2, при этом изредка имея простой одного сервера? Какую часть «доходов будущих периодов», т.е. предоплаты клиентов мы можем безболезненно потратить, зная что такое-то время они нам не понадобятся?
Все эти вопросы можно предусмотреть в гибком плане счетов. При этом бухгалтерия не совсем подходит для такого, ведь это чисто управленческий учет.
План счетов, субсчета, двойные проводки и универсальные ИД документов двигающих биллинг (например GUID + тип документа, и уже у каждого документа своя отдельная таблица, которую мы выбираем по типу документа, полученному по GUID). Абстрактный класс для документов, в реализации даем движение конкретных счетов… Ну а в остальном как у Вас…
Но я бы таки за основу брал двойную запись.
Она дает значительную гибкость.
Проводка она не даром двойная. Это дает очень большую гибкость.
Наличие баланса позволяет легко проверить/восстановить целостность.
Целостность движения денег дает множество дополнительных управленческих отчетов.
Внимательно смотрим схему. На самом деле двойная запись есть. Но в виде журнала, а не раздельных счетов. Я рассматривал вариант с раздельными счетами для дебита кредита а так же различных услуг. Как итог пришел к выводу что это сильно усложнит схему и оставил только журнал проводок с дебитом и кредитом. Баланс кстати четко привязан к ним, что позволяет в случае необходимости верифицировать баланс по журналу проводок. Разнесение на раздельные счета и т.п. делается уже отдельно в 1С/SAP. Т.е. в любом случае я предполагаю что в конце месяца происходит выгрузка в нормальную бухгалтерскую систему.
Делаем из этого биллинга биллинг торговли. Слишком большие изменения выходят. Склады, закупочные цены…
Делаем биллинг ресторана. С себестоимостями и т.п., ведь надо и калькуляции и склад…
Ничего подобного :) Расширить да. Изменения? Нет. Если вы считаете что только расширения схемы мало, то я хотел бы услышать что с вашей точки зрения в этой схеме мешает.
Нам ведь нужно управлять скидками? А значит нужна себестоимость. Хоть какая.
У меня управление скидками никак не затрагивается. Это вообще отдельная тема для разговора, что как и почему. И для каждой предметной области управление скидками будет свое.
ABC-отчет нужен?
С таким отчетом как-то не сталкивался.
План счетов может быть абсолютно любой, а субсчета прекрасно привязываются к «договорам».
Что тут подразумевается под планом счетов? Я просто не совсем понимаю механику.
А если нам нужно делать еще один налог. Типа налог с продаж. Похож на НДС, но помимо НДС и с другой логикой?
В чем выражается другая логика? Налог с продаж в целом НДС и выражает. Тут НДС то введено исключительно из-за того что он взимается на стадии начисления. И его вынос в большую SAP систему доставляет слишком много сложностей.
универсальные ИД документов двигающих биллинг (например GUID + тип документа, и уже у каждого документа своя отдельная таблица, которую мы выбираем по типу документа, полученному по GUID).
Такое я не стал закладывать так-как считаю в таких случаях по проводкам.
Да 1C/SAP при этом никуда не девается. Это скорее не для вас, а для остальных. ;)
Простите, я думал у вас чуть лучше понимание терминологии. Моя вина.
Я как-то начинал писать статью «бухгалтерия для программиста», с основами терминологии, но всё время не найду поправить ее красоту.
Попробую здесь кратко:
1 — основа бухгалтерии это двойная запись. Любая проводка (экзотику оставим за скобками) состоит из трех основных полей: номер счета который дебетуем, номер счета который кредетуем и сумма. Т.е. у нас ВСЕГДА меняется два счета на одну сумму.
2 — термины «дебет и кредит» не являются синонимами слов «приход и расход». В половине случаев они меняются местами.
3 — счета не бывают «кредитовыми» и «дебетовыми». Так нельзя говорить потому что и пассивные и активные счета дебетуются и кредитуются. Так что у нас есть два вида счетов — Активные и Пассивные. Разницу в комментарии не описать, поэтому пока пропущу. Что важно — сумма активных счетов всегда равна сумме пассивных счетов. Это называется баланс. (Также баланс это список сумм на счетах которые мы тут считаем, и собственно эта самая цифра которая равна).
4 — Дебет у нас увеличивает активный счет, и уменьшает пассивный, кредит же наоборот уменьшает активный и увеличивает пассивный. Такая слегка запутывающая схема придумана для того, чтобы у нас сохранялся баланс и при этом у нас наша универсальная операция работала бы как при операциях между активным и пассивным счетом, так и между двумя активными или двумя пассивными…
5 — список наших счетов с их свойствами (актив/пассив) называется «план счетов»
6 — данная схема удобна не только для бухгалтерии где планы счетов регламентированны, но и для управленческого учета, где ты делаешь что хочешь, под свои задачи. Это важно. 1С-бухгалтерия это именно бухгалтерия…
Краткий (очень краткий) пример:
В начале у нас всё по нулям.
Первой операцией у нас будет квитанция от вебмани о поступлении денег в пользу клиента «Иван».
Мы создаем документ «пополнение», со всеми реквизитами, и параллельно делаем следующие проводки:
Дебет активного счета «Средства на вебмани», Кредит пассивного «Доходы будущих периодов», субсчет «Счет клиента Иван», сумма == 100руб.
Следующим документом мы покупаем у ДЦ «Розочка» ресселерский акк, у которого рессурсов хватит на два таких клиента. Оплачиваем вебмани.
Проводки:
Дебит активного «Оплаченные хостинги», субсчет «ДЦ Розочка, ресселинг А», Кредит активного «Средства вебмани», сумма 50 руб.
Ну и третий документ — покупка клиентом хостинга на месяц и списание за него денег (Клиенту стоит 50руб). Проводки такие:
Дебит пассивного «Доходы будущих периодов», субсчет «Счет клиента Иван», Кредит активного «Оплаченные хостинги», субсчет «ДЦ Розочка, ресселинг А», сумма 25 руб.
Дебит пассивного «Доходы будущих периодов», субсчет «Счет клиента Иван», кредит пассивного «Нераспределенная прибыль», сумма 25руб.
Баланс на выходе:
Активы:
Деньги на вебманях = 50руб.
Оплаченные хостинги = 25руб.
Пассивы:
«Доходы будущих периодов», субсчет «Счет клиента Иван» = 50руб.
«Нераспределенная прибыль» = 25руб.
Такая схема дает больше возможностей, при этом проще.
У нас всего три сущности было: Счет, Проводка и Документ.
Да, Документы бывают разных типов, но уже бизнеслогика, а скелет можно разместить в абстрактном классе.
Я как-то начинал писать статью «бухгалтерия для программиста», с основами терминологии, но всё время не найду поправить ее красоту.
Попробую здесь кратко:
1 — основа бухгалтерии это двойная запись. Любая проводка (экзотику оставим за скобками) состоит из трех основных полей: номер счета который дебетуем, номер счета который кредетуем и сумма. Т.е. у нас ВСЕГДА меняется два счета на одну сумму.
2 — термины «дебет и кредит» не являются синонимами слов «приход и расход». В половине случаев они меняются местами.
3 — счета не бывают «кредитовыми» и «дебетовыми». Так нельзя говорить потому что и пассивные и активные счета дебетуются и кредитуются. Так что у нас есть два вида счетов — Активные и Пассивные. Разницу в комментарии не описать, поэтому пока пропущу. Что важно — сумма активных счетов всегда равна сумме пассивных счетов. Это называется баланс. (Также баланс это список сумм на счетах которые мы тут считаем, и собственно эта самая цифра которая равна).
4 — Дебет у нас увеличивает активный счет, и уменьшает пассивный, кредит же наоборот уменьшает активный и увеличивает пассивный. Такая слегка запутывающая схема придумана для того, чтобы у нас сохранялся баланс и при этом у нас наша универсальная операция работала бы как при операциях между активным и пассивным счетом, так и между двумя активными или двумя пассивными…
5 — список наших счетов с их свойствами (актив/пассив) называется «план счетов»
6 — данная схема удобна не только для бухгалтерии где планы счетов регламентированны, но и для управленческого учета, где ты делаешь что хочешь, под свои задачи. Это важно. 1С-бухгалтерия это именно бухгалтерия…
Краткий (очень краткий) пример:
В начале у нас всё по нулям.
Первой операцией у нас будет квитанция от вебмани о поступлении денег в пользу клиента «Иван».
Мы создаем документ «пополнение», со всеми реквизитами, и параллельно делаем следующие проводки:
Дебет активного счета «Средства на вебмани», Кредит пассивного «Доходы будущих периодов», субсчет «Счет клиента Иван», сумма == 100руб.
Следующим документом мы покупаем у ДЦ «Розочка» ресселерский акк, у которого рессурсов хватит на два таких клиента. Оплачиваем вебмани.
Проводки:
Дебит активного «Оплаченные хостинги», субсчет «ДЦ Розочка, ресселинг А», Кредит активного «Средства вебмани», сумма 50 руб.
Ну и третий документ — покупка клиентом хостинга на месяц и списание за него денег (Клиенту стоит 50руб). Проводки такие:
Дебит пассивного «Доходы будущих периодов», субсчет «Счет клиента Иван», Кредит активного «Оплаченные хостинги», субсчет «ДЦ Розочка, ресселинг А», сумма 25 руб.
Дебит пассивного «Доходы будущих периодов», субсчет «Счет клиента Иван», кредит пассивного «Нераспределенная прибыль», сумма 25руб.
Баланс на выходе:
Активы:
Деньги на вебманях = 50руб.
Оплаченные хостинги = 25руб.
Пассивы:
«Доходы будущих периодов», субсчет «Счет клиента Иван» = 50руб.
«Нераспределенная прибыль» = 25руб.
Такая схема дает больше возможностей, при этом проще.
У нас всего три сущности было: Счет, Проводка и Документ.
Да, Документы бывают разных типов, но уже бизнеслогика, а скелет можно разместить в абстрактном классе.
Тот момент, когда комментарий достоен поста.
И да, ждем отдельную, подробную статью
И да, ждем отдельную, подробную статью
1 — основа бухгалтерии это двойная запись. Любая проводка (экзотику оставим за скобками) состоит из трех основных полей: номер счета который дебетуем, номер счета который кредетуем и сумма. Т.е. у нас ВСЕГДА меняется два счета на одну сумму.
Я в курсе. И да я в курсе так же что у вас этих счетов может быть больше двух. Это очень громоздкая схема и вот в АСР ее использовать ее с моей точки зрения весьма и весьма накладно.
2 — термины «дебет и кредит» не являются синонимами слов «приход и расход». В половине случаев они меняются местами.
В случае если у вас насколько счетов то да. АСР с моей точки зрения это система в первую очередь для клиентов. По этой причине два счета в системе отсутствуют.
3 — счета не бывают «кредитовыми» и «дебетовыми». Так нельзя говорить потому что и пассивные и активные счета дебетуются и кредитуются. Так что у нас есть два вида счетов — Активные и Пассивные. Разницу в комментарии не описать, поэтому пока пропущу. Что важно — сумма активных счетов всегда равна сумме пассивных счетов. Это называется баланс. (Также баланс это список сумм на счетах которые мы тут считаем, и собственно эта самая цифра которая равна).
3 — счета не бывают «кредитовыми» и «дебетовыми». Так нельзя говорить потому что и пассивные и активные счета дебетуются и кредитуются. Так что у нас есть два вида счетов — Активные и Пассивные. Разницу в комментарии не описать, поэтому пока пропущу. Что важно — сумма активных счетов всегда равна сумме пассивных счетов. Это называется баланс. (Также баланс это список сумм на счетах которые мы тут считаем, и собственно эта самая цифра которая равна).
4 — Дебет у нас увеличивает активный счет, и уменьшает пассивный, кредит же наоборот уменьшает активный и увеличивает пассивный. Такая слегка запутывающая схема придумана для того, чтобы у нас сохранялся баланс и при этом у нас наша универсальная операция работала бы как при операциях между активным и пассивным счетом, так и между двумя активными или двумя пассивными…
5 — список наших счетов с их свойствами (актив/пассив) называется «план счетов»
6 — данная схема удобна не только для бухгалтерии где планы счетов регламентированны, но и для управленческого учета, где ты делаешь что хочешь, под свои задачи. Это важно. 1С-бухгалтерия это именно бухгалтерия…
Опять же вернемся к началу АСР не бухгалтерия. Нам более важно чтобы у нас начисления и платежи были не противоречивы и баланс клиента всегда был вычисляем.
Теперь давайте по вашему краткому примеру:
Первой операцией у нас будет квитанция от вебмани о поступлении денег в пользу клиента «Иван».
Мы создаем документ «пополнение», со всеми реквизитами, и параллельно делаем следующие проводки:
Дебет активного счета «Средства на вебмани», Кредит пассивного «Доходы будущих периодов», субсчет «Счет клиента Иван», сумма == 100руб.
Окей первая операция есть в биллинге. Создается платеж и проводка.
Следующим документом мы покупаем у ДЦ «Розочка» ресселерский акк, у которого рессурсов хватит на два таких клиента. Оплачиваем вебмани.
Проводки:
Дебит активного «Оплаченные хостинги», субсчет «ДЦ Розочка, ресселинг А», Кредит активного «Средства вебмани», сумма 50 руб.
А тут внимание. Этой части в АСР в таком виде нет.
Ну и третий документ — покупка клиентом хостинга на месяц и списание за него денег (Клиенту стоит 50руб). Проводки такие:
Дебит пассивного «Доходы будущих периодов», субсчет «Счет клиента Иван», Кредит активного «Оплаченные хостинги», субсчет «ДЦ Розочка, ресселинг А», сумма 25 руб.
Дебит пассивного «Доходы будущих периодов», субсчет «Счет клиента Иван», кредит пассивного «Нераспределенная прибыль», сумма 25руб.
Этот документ есть.
Такая схема дает больше возможностей, при этом проще.
У нас всего три сущности было: Счет, Проводка и Документ.
Да, Документы бывают разных типов, но уже бизнеслогика, а скелет можно разместить в абстрактном классе.
Проблема в том что вы пытаетесь втащить фактически полный бух. учет в систему. В том числе еще поди и расчеты зарплат можно внести и т.п. А биллинги в России не зря называются АСР фактически же полная формулировка звучит как Автоматизированная система расчетов с клиентами. Т.е. она решает только одну часть это автоматизация работы с клиентами. Да ее можно выполнить как модуль к SAP. Но могут возникнуть проблемы с производительностью и слишком большого числа допила специфической части предметной части. По этой причине как правило АСР выполняется в урезанном по бух. учету функционале. К примеру в ней плана счетов. Считается что есть только один счет обращенный к клиенту.
Ну вопросов к вашей реализации у меня было два:
1 — вы используете бухгалтерские термины там, где им не место, и таким образом, что это искажает смысл. Пишите уж «приход-расход», или что-то другое. Дебет и Кредит созданы именно для того, чтобы отразить это явление, когда у пассивных счетов это одно, а у активных другое… Плюс обычно под дебетом подразумевают НОМЕР дебетуемого счета. В общем тому кто понимает, оно немного неудобно, и запутывает. Тому же, кто не знает таких слов, так и подавно оно непонятно.
2 — Ваша схема при всех ее преимуществах заточена под довольно узкую сферу. Слишком ограниченная реализация.
Вы очень хорошо прописали многие классические ошибки. Например объяснили почему нужно сторнировать (корректирующая проводка в вашей терминологии), а не удалять, почему лучше делать ввод остатков, а не фиктивные платежи…
Но данное решение это частный случай, с планом счетов состоящим из одного внебалансового активного счета (хотя правильнее было его делать пассивным, но тут без особой разницы)…
Вы ошибочно разделяете биллинг и бухгатлерию, не оставив места управленческому учету. Тут есть несколько факторов:
стандартные, готовые управленческие решения нам могут не подходить, а поскольку в отличии от бухгалтерии этот вопрос не регламентирован государством, то мы можем иметь любые пожелания… писать с нуля? Отдельно? Третьей системой? Т.е. мы пишем биллинг, пишем отдельно от него управленческий учет, который дублирует биллинг, и частично бухгалтерию. Потом делаем синхронизацию этих трех систем… ну допустим.
Но вот задача — раздельный учет денег приходящих из разных платежных систем, потому что у нас на разных счетах лежат деньги, и расходы нужно как-то оптимизировать с учетом платежных систем… Скажите, куда интегрировать этот учет? Бухгалтерия его не поддерживает. У вас оно не надо, и сложно… добавляем в управленческий.
Теперь вопрос — платежная система будет информацию отправлять и в биллинг и в упр.учет? Нет, в одно… а в какое? Очевидно что в биллинг, ведь иначе зачем он нам вообще? Ведь все данные биллинга в управленческом уже есть… из биллинга информация идет в управленческий учет, потом из него идет в бухгалтерию? Или сначала в бухгалтерию? Или и в бухгалтерию и в управленческий из биллинга? И во всех трех у нас будет своя цифра по счетам. Где-то не успели синхронизировать, где-то сбой… Рано или поздно с ростом сложности задач будет принято решение выкинуть эту урезанную прослойку под названием «биллинг» и перенести ее в управленческий учет.
Мне кажется (кажется это значит что могу ошибаться), что Вы плохо понимаете бухучет, и поэтому считаете, что его принципы используются только в бухгалтерии… Может вам будет проще, если я буду называть управленческий учет «черной бухгалтерией»? Хотя черный и отдает некоей незаконностью, что не всегда так, но может так понятнее будет.
1 — вы используете бухгалтерские термины там, где им не место, и таким образом, что это искажает смысл. Пишите уж «приход-расход», или что-то другое. Дебет и Кредит созданы именно для того, чтобы отразить это явление, когда у пассивных счетов это одно, а у активных другое… Плюс обычно под дебетом подразумевают НОМЕР дебетуемого счета. В общем тому кто понимает, оно немного неудобно, и запутывает. Тому же, кто не знает таких слов, так и подавно оно непонятно.
2 — Ваша схема при всех ее преимуществах заточена под довольно узкую сферу. Слишком ограниченная реализация.
Вы очень хорошо прописали многие классические ошибки. Например объяснили почему нужно сторнировать (корректирующая проводка в вашей терминологии), а не удалять, почему лучше делать ввод остатков, а не фиктивные платежи…
Но данное решение это частный случай, с планом счетов состоящим из одного внебалансового активного счета (хотя правильнее было его делать пассивным, но тут без особой разницы)…
Вы ошибочно разделяете биллинг и бухгатлерию, не оставив места управленческому учету. Тут есть несколько факторов:
стандартные, готовые управленческие решения нам могут не подходить, а поскольку в отличии от бухгалтерии этот вопрос не регламентирован государством, то мы можем иметь любые пожелания… писать с нуля? Отдельно? Третьей системой? Т.е. мы пишем биллинг, пишем отдельно от него управленческий учет, который дублирует биллинг, и частично бухгалтерию. Потом делаем синхронизацию этих трех систем… ну допустим.
Но вот задача — раздельный учет денег приходящих из разных платежных систем, потому что у нас на разных счетах лежат деньги, и расходы нужно как-то оптимизировать с учетом платежных систем… Скажите, куда интегрировать этот учет? Бухгалтерия его не поддерживает. У вас оно не надо, и сложно… добавляем в управленческий.
Теперь вопрос — платежная система будет информацию отправлять и в биллинг и в упр.учет? Нет, в одно… а в какое? Очевидно что в биллинг, ведь иначе зачем он нам вообще? Ведь все данные биллинга в управленческом уже есть… из биллинга информация идет в управленческий учет, потом из него идет в бухгалтерию? Или сначала в бухгалтерию? Или и в бухгалтерию и в управленческий из биллинга? И во всех трех у нас будет своя цифра по счетам. Где-то не успели синхронизировать, где-то сбой… Рано или поздно с ростом сложности задач будет принято решение выкинуть эту урезанную прослойку под названием «биллинг» и перенести ее в управленческий учет.
Мне кажется (кажется это значит что могу ошибаться), что Вы плохо понимаете бухучет, и поэтому считаете, что его принципы используются только в бухгалтерии… Может вам будет проще, если я буду называть управленческий учет «черной бухгалтерией»? Хотя черный и отдает некоей незаконностью, что не всегда так, но может так понятнее будет.
1 — вы используете бухгалтерские термины там, где им не место, и таким образом, что это искажает смысл. Пишите уж «приход-расход», или что-то другое. Дебет и Кредит созданы именно для того, чтобы отразить это явление, когда у пассивных счетов это одно, а у активных другое… Плюс обычно под дебетом подразумевают НОМЕР дебетуемого счета. В общем тому кто понимает, оно немного неудобно, и запутывает. Тому же, кто не знает таких слов, так и подавно оно непонятно.
Это кстати хорошее замечание. С терминологией вообще много путаницы. В принципе таблица стороны учета позволяет сделать не дебет/кредит а приход/расход. И на механику это никак не повлияет.
2 — Ваша схема при всех ее преимуществах заточена под довольно узкую сферу. Слишком ограниченная реализация.
Есть такое. Но тут есть еще такой момент, весьма часто требуется сделать отдельную систему которая с типичной бухгатерией или SAP системой связана только опосредовано. К примеру требуются данные только по завершению отчетного периода, до этого всю эту информацию тащить не есть хорошо.
Вы очень хорошо прописали многие классические ошибки. Например объяснили почему нужно сторнировать (корректирующая проводка в вашей терминологии), а не удалять, почему лучше делать ввод остатков, а не фиктивные платежи…
Но данное решение это частный случай, с планом счетов состоящим из одного внебалансового активного счета (хотя правильнее было его делать пассивным, но тут без особой разницы)…
Внесение большего числа счетов делает систему сложнее для понимания, для остальных. А если прятать от части пользователей счета, то начинается свистопляска со стороны тех кто эти счета хочет настроить под себя. Так что это сознательное действие.
Вы ошибочно разделяете биллинг и бухгатлерию, не оставив места управленческому учету. Тут есть несколько факторов:
стандартные, готовые управленческие решения нам могут не подходить, а поскольку в отличии от бухгалтерии этот вопрос не регламентирован государством, то мы можем иметь любые пожелания… писать с нуля? Отдельно? Третьей системой? Т.е. мы пишем биллинг, пишем отдельно от него управленческий учет, который дублирует биллинг, и частично бухгалтерию. Потом делаем синхронизацию этих трех систем… ну допустим.
Насколько это ошибочно, это вопрос хороший. Но это типичный подход, бухгалтерию от биллинга отделяют довольно часто. Опять же мне не совсем понятно что тут под управленческим учетом подразумевается? Я просто не сталкивался с этим понятием. Ссылочка бы не помешала. Пока я так понял это система которая как-то показывает то какие у нас расходы и доходы и как они складываются.
Теперь вопрос — платежная система будет информацию отправлять и в биллинг и в упр.учет? Нет, в одно… а в какое? Очевидно что в биллинг, ведь иначе зачем он нам вообще? Ведь все данные биллинга в управленческом уже есть… из биллинга информация идет в управленческий учет, потом из него идет в бухгалтерию? Или сначала в бухгалтерию? Или и в бухгалтерию и в управленческий из биллинга? И во всех трех у нас будет своя цифра по счетам. Где-то не успели синхронизировать, где-то сбой… Рано или поздно с ростом сложности задач будет принято решение выкинуть эту урезанную прослойку под названием «биллинг» и перенести ее в управленческий учет.
Платежи и начисления в биллинге. Далее данные из биллинга в бухгалтерию по завершению отчетного периода. Для понимания что попадает в управленческий учет, мне нужно понять что имеется ввиду под управленческим учетом.
Мне кажется (кажется это значит что могу ошибаться), что Вы плохо понимаете бухучет, и поэтому считаете, что его принципы используются только в бухгалтерии… Может вам будет проще, если я буду называть управленческий учет «черной бухгалтерией»? Хотя черный и отдает некоей незаконностью, что не всегда так, но может так понятнее будет.
Вполне возможно я недостаточно понимаю бух. учет. Но эта проблема есть у многих. И еще есть другая проблема когда начинают тащить полный бух. учет, то получается система которую понимают только люди плотно знакомые с этой областью. И что еще хуже они не пытаются адаптировать решения так чтобы этим мог пользоваться простой смертный. А биллинг все же та система которой хотелось бы чтобы могли пользоваться и простые смертные.
Непонимание бухучета это проблема не бухучета или того кто не понимает, а того что нет адекватных материалов. может есть какие-то популярные статьи или учебники (наверняка есть), но в основном пишут просто сухие факты, от которых нифига не понятно. Я разобрался с бухучетом только когда потратил два часа на написание заметки в стиле «давайте изобретем бухучет», разбираясь зачем сделано так, а не иначе… Читая сухую информацию из справочника или википедии мы обычно пытаемся спроецировать ее на наше обычное понимание, и получается каша. Ну да это оффтоп.
Соглашусь с Вами что «полная бухгалтерия», да еще и сохранение бухгалтерской терминологии и т.п. делает продукт неработоспособным.
Также хочу уточнить, что я не навязываю, что синтетические счета с двойной записью это панацея. Вы спросили мол кто бы что сделал иначе, я и озвучил :)
Управленческий учет я бы коротко охарактеризовал как бухгалтерию которая ведется для целей управления бизнесом, а не для взаимодействий с гос.органами или инвесторами и т.п. Все хорошие продукты управленческого учета внутри себя содержат некий план счетов, стандартные двойные проводки и т.п., но частично скрывают эту структуру от пользователя, чтобы не путать его терминологией и т.п. В противопоставление управленческому можно поставить регламентированный, т.е. тот, который нам регламентируют, по которому есть регламент и т.п., например инструкция по бухучету, утвержденный кабмином план счетов и т.п.
Пример управленческого учета — пользователь ведет деятельность от имени «Бюджетного автомата» (вебмани), т.е. «в серую», или от имени оффшора. Его учет никак не регламентирован. Бухгалтерские решения для такого пользователя будут очень громоздкими и тяжелыми. Редактировать же руками готовую конфигурацию будет не менее сложно, слишком много надо удалять, резать связи между сущностями… брр… и все равно будет что-то несуразное.
При этом сами принципы бухучета вполне себе удобны для учета собственных средств, и порядка с финансами.
У нас может быть много денег или много других активов, при этом может быть много долгов… Долги эти разделяются на те что надо платить уже, скоро или нескоро… всё это влияет на наши решения по различным сделкам. И всё это хочется видеть в удобном виде…
Второй пример — у предприятия есть регламентированный учет, но в реальности деятельность ведется от имени нескольких лиц. Например общепит часто имеет ИП для продажи еды, и безалкоголя, и юрлицо для алкоголя. Или группа СПД (украинский аналог ИП, не знаю есть ли такая практика в РФ, налогообложение ИП не знаю) используется для продажи в розницу, а склад и опт идут от имени юрлица. Иногда двух или трех юрлиц.
У каждого лица своя бухгалтерия, даже если они в одной базе, они относительно самостоятельны. Просто сложить их не получится, ведь у нас есть множество операций внутри нашей группы, и для управленческих решений это будет лишним, часто хочется видеть реальную картину, что пришло, что ушло, кому заплатили, от кого получили… кому должны, кто должен… без учета внутренних отношений, только внешние движения, общая сумма активов и т.п…
Частным случаем управленческого учета является черная бухгалтерия. Но это не единственное и не основное назначение.
Для всего этого нужен управленческий учет.
Соглашусь с Вами что «полная бухгалтерия», да еще и сохранение бухгалтерской терминологии и т.п. делает продукт неработоспособным.
Также хочу уточнить, что я не навязываю, что синтетические счета с двойной записью это панацея. Вы спросили мол кто бы что сделал иначе, я и озвучил :)
Управленческий учет я бы коротко охарактеризовал как бухгалтерию которая ведется для целей управления бизнесом, а не для взаимодействий с гос.органами или инвесторами и т.п. Все хорошие продукты управленческого учета внутри себя содержат некий план счетов, стандартные двойные проводки и т.п., но частично скрывают эту структуру от пользователя, чтобы не путать его терминологией и т.п. В противопоставление управленческому можно поставить регламентированный, т.е. тот, который нам регламентируют, по которому есть регламент и т.п., например инструкция по бухучету, утвержденный кабмином план счетов и т.п.
Пример управленческого учета — пользователь ведет деятельность от имени «Бюджетного автомата» (вебмани), т.е. «в серую», или от имени оффшора. Его учет никак не регламентирован. Бухгалтерские решения для такого пользователя будут очень громоздкими и тяжелыми. Редактировать же руками готовую конфигурацию будет не менее сложно, слишком много надо удалять, резать связи между сущностями… брр… и все равно будет что-то несуразное.
При этом сами принципы бухучета вполне себе удобны для учета собственных средств, и порядка с финансами.
У нас может быть много денег или много других активов, при этом может быть много долгов… Долги эти разделяются на те что надо платить уже, скоро или нескоро… всё это влияет на наши решения по различным сделкам. И всё это хочется видеть в удобном виде…
Второй пример — у предприятия есть регламентированный учет, но в реальности деятельность ведется от имени нескольких лиц. Например общепит часто имеет ИП для продажи еды, и безалкоголя, и юрлицо для алкоголя. Или группа СПД (украинский аналог ИП, не знаю есть ли такая практика в РФ, налогообложение ИП не знаю) используется для продажи в розницу, а склад и опт идут от имени юрлица. Иногда двух или трех юрлиц.
У каждого лица своя бухгалтерия, даже если они в одной базе, они относительно самостоятельны. Просто сложить их не получится, ведь у нас есть множество операций внутри нашей группы, и для управленческих решений это будет лишним, часто хочется видеть реальную картину, что пришло, что ушло, кому заплатили, от кого получили… кому должны, кто должен… без учета внутренних отношений, только внешние движения, общая сумма активов и т.п…
Частным случаем управленческого учета является черная бухгалтерия. Но это не единственное и не основное назначение.
Для всего этого нужен управленческий учет.
Непонимание бухучета это проблема не бухучета или того кто не понимает, а того что нет адекватных материалов. может есть какие-то популярные статьи или учебники (наверняка есть), но в основном пишут просто сухие факты, от которых нифига не понятно. Я разобрался с бухучетом только когда потратил два часа на написание заметки в стиле «давайте изобретем бухучет», разбираясь зачем сделано так, а не иначе… Читая сухую информацию из справочника или википедии мы обычно пытаемся спроецировать ее на наше обычное понимание, и получается каша.
Вот это уж точно. Мне так же пришлось убить много времени для понимания что там и как. А так же собственно большиство бухгалтеров что с этим работают к сожалению воспринимают схему как «это дано нам свыше». Такая библия вида если делать так то все будет хорошо :)
Для всего этого нужен управленческий учет.
Ага это вы про BI. Так понятнее стало. Ну вот в том что вы описали как раз таки есть посыл к тому чтобы управленческий учет был независимым и от биллинга и от бухгалтерии. Так-как он должен увязывать в одну систему кучу разнородной информации из разных систем, для получения аналитики. Таким образом тащить управленческий учет в какую либо систему вообще губительно. Это как раз таки должна быть отдельная система с возможностью простого подключения источников данных.
Это как раз таки должна быть отдельная система с возможностью простого подключения источников данных.
А смысл делать его отдельно? Всё что есть в биллинге у нас дублируется в управленческом учете.
Единственный смысл, если биллинг и управ.учет делается на разных технологиях. Типа биллинг смотрит в Интернет, а внутренняя часть работает в виде компилируемого приложения а не в интранете…
большиство бухгалтеров что с этим работают к сожалению воспринимают схему как «это дано нам свыше»
Ага. Сначала он не может ответить почему собственный капитал это пассив, потом почему убытки это актив, а потом смотрит в баланс и ничего не видит. Но зато точно знает как правильно его составить :)
Собственно поэтому руководителю приходится изучать бухучет, чтобы хоть на пальцах подсказывать бухгалтеру о том, что одну и ту же операцию можно провести по разному, получив разный результат…
А смысл делать его отдельно? Всё что есть в биллинге у нас дублируется в управленческом учете.
Есть причем довольно большой. Это позволит не иметь привязку управленческого учета к биллингу.Если делать управленческий учет в биллинге, то придется и добавление других источников расходов/доходов. Плюс это позволит сделать биллинг и управленческий учет более управляемым. У меня помнится тоже были мучения делить биллинг и CRM или нет. В итоге вышло что все же делить. Точек функционала оказалось довольно много.
Единственный смысл, если биллинг и управ.учет делается на разных технологиях. Типа биллинг смотрит в Интернет, а внутренняя часть работает в виде компилируемого приложения а не в интранете…
Или биллинг как источник данных может меняться.
>> А смысл делать его отдельно? Всё что есть в биллинге у нас дублируется в управленческом учете.
Для нужд управленческого учета информация по каждому клиенту попросту не нужна. Минимальная разбивка агреггированные данные по категориям клиентов, например: Физлица/Юрлица, Частный сектор/Микрорайоны/сельская местность и так далее… Причем это разбивка может меняться в зависимости от принятой учётной политики, маркетинговых целей и кучи всего остального чуть ли не каждый год, а то и чаще…
Для нужд управленческого учета информация по каждому клиенту попросту не нужна. Минимальная разбивка агреггированные данные по категориям клиентов, например: Физлица/Юрлица, Частный сектор/Микрорайоны/сельская местность и так далее… Причем это разбивка может меняться в зависимости от принятой учётной политики, маркетинговых целей и кучи всего остального чуть ли не каждый год, а то и чаще…
Ага это вы про BI.
Небольшое уточнение. BI — это Business Intelligence, целью которого является обработка по большей части неструктурированных (и часто даже нефинансовых) данных. А управленческий учет — это Managerial Accounting. И там, кстати, есть вполне стандартизированные методики, которые легко ложатся на данные из биллинга и бухгалтерии.
Биллинг — это прежде всего система обслуживания клиента. Он относится к УУ и БУ как один из инструментов, источников информации…
Попытка сделать её непосредственной частью системы управленческого учета (или бухгалтерского) приводит к нездоровому усложнению системы. Применение бухгалтерских терминов лишь усугубляет неправильное восприятие, тут вы правы.
Попытка сделать её непосредственной частью системы управленческого учета (или бухгалтерского) приводит к нездоровому усложнению системы. Применение бухгалтерских терминов лишь усугубляет неправильное восприятие, тут вы правы.
Офтоп, конечно, но эти id_xxx меня протос убивают.
Прям интересно стало сколько людей придеживается написания xxx_id, а сколько id_xxx
И откуда ноги ростут у этого дела? :)
Прям интересно стало сколько людей придеживается написания xxx_id, а сколько id_xxx
И откуда ноги ростут у этого дела? :)
Я подозреваю из естественного языка. Смотрите в русском языке:
идентификатор объекта (типа начислений и т.п.)
Отсюда id_object
В английском языке строго наоборот:
Object id
Отсюда object_id
идентификатор объекта (типа начислений и т.п.)
Отсюда id_object
В английском языке строго наоборот:
Object id
Отсюда object_id
Но ведь в итоге пишется все на английском языке, и было бы естественее использовать второй вариант :)
Мне привычнее id_object. Никто вам не мешает изменить в своей схеме как привычнее вам. Просто не забывайте описывать это в документации.
Честно говоря, со скидкой нифига не понял.
Она действует на весь лицевой счет, а не на конкретную услугу?
Или как?
И что, на каждое начисление создается еще и позиция в discount дабы отрозить скидку на это начисление?
Не проще ли эту информацию сразу в начислениях хранить?
Она действует на весь лицевой счет, а не на конкретную услугу?
Или как?
И что, на каждое начисление создается еще и позиция в discount дабы отрозить скидку на это начисление?
Не проще ли эту информацию сразу в начислениях хранить?
Честно говоря, со скидкой нифига не понял.
Она действует на весь лицевой счет, а не на конкретную услугу?
Или как?
А никак :) Схема определяет только что скидка предоставляется на конкретное начисление. То каким образом она предоставляется тут нет :)
И что, на каждое начисление создается еще и позиция в discount дабы отрозить скидку на это начисление?
Не проще ли эту информацию сразу в начислениях хранить?
Да на каждое начисление. Нет не проще. Фишка в том что в случае если скидка идет отдельным документом, то добавлять или аннулировать скидку вы можете отдельно. К тому же если к примеру у вас клиенту предоставляется несколько скидок, нет проблем с пониманием откуда и как она возникла. В случае если позицию discount отобразить в начисление проблема у вас такая будет. Так же это препятствует некорректному наложению скидок. При такой схеме скидку по начислению уже по скидке как сами понимаете сделать нельзя.
Про ввод остатков, что мешает делать их фиктивными платежами с соответствующим типом?
В схеме немного не понял. А как к договору привязываются услуги? Не само начисление, а именно какую услугу следует начислять. Например есть «Услуга1», «Услуга2». Должна же быть таблика которая указыват что «Договор 1» использует «Услуга 2», «Договор 2» использует «Услуга 1» и «Услуга 2» одновременно.
Смотрите опрос последний пункт. Тут нет части которая говорит по каким критериям начисляем. Эта схема говорит как хранить.
Спасибо. Было бы интересно и 1-й пункт, хотя бы на уровне SQL, по каждому действию. И последний пункт =)
Какую литературу можно почитать по архитектуре АСР?
Какую литературу можно почитать по архитектуре АСР?
Какую литературу можно почитать по архитектуре АСР?
А нету ее. Опять же это стык разных по сути дела предметных областей. Встречаются тут бухучет, программирование и та предметная область для которой делается АСР. Самая главная тут вещь все же бухучет. Так что его курить строго рекомендую.
Предметная область всегда играет наиболее важную роль, она может принести очень много специфики в чарждах, тарифах, скидках да вообще во всем начиная с самой структуры.
Соглашусь, предметная область очень сильно влияет на способы расчета стоимости услуги. От разницы в пред и пост оплатной системы до индивидуальных способов расчета налогов (другая страна/вип-клиент, и т.д.)
И да и нет. Может принести в вопросе сколько и в какое время. А вот как разместить в БД будет в целом одинаково. Попробуйте сами придумать такую специфику, чтобы приведенная схема не работала.
Ну на сколько я понимаю, основа в принципе одинакова. Учет расчета с клиентами согласно оказанных услуг? В принципе и ваша схема, на сколько я понимаю, для того и выложена как основа. Потому думал может есть где почитать, посмотреть на практики других людей в этой сфере.
ИМХО, Смысл АСР (биллинга) в том, чтобы посчитать, сколько стоит услуга для клиента в разрезе различных параметров: скидки, акции, бонусы, выходные/праздники, и т.д. от менеджеров, если есть необходимость, себестоимость услуги, либо её стоимость от сторонних поставщиков. Соответственно, в АСР должна быть система учета данных услуг с тарифными планами и прочим. Вне зависимости от предметной области. У Вас же представлена только та часть, что отвечает за фин. документы, дело полезное, но для полноценной АСР маловато будет. Для примера, из моего опыта (работаю биллингистом в ТТК), из предметной области телекоммуникаций. Абонентская плата за услугу, по конкретному тарифному плану, с изменением статуса абонента при уходе баланса в минус, и просьбе абонента о доверительном платеже (допустим, 15 рублей), включает абонента на 10 дней до реальной оплаты АП. Сколько таблиц нужно добавить в Вашу схему, по Вашему мнению?
ИМХО, Смысл АСР (биллинга) в том, чтобы посчитать, сколько стоит услуга для клиента в разрезе различных параметров: скидки, акции, бонусы, выходные/праздники, и т.д. от менеджеров, если есть необходимость, себестоимость услуги, либо её стоимость от сторонних поставщиков. Соответственно, в АСР должна быть система учета данных услуг с тарифными планами и прочим.
Это будет. Так-как текущая схема отвечает только как хранить.
У Вас же представлена только та часть, что отвечает за фин. документы, дело полезное, но для полноценной АСР маловато будет.
Проблема в том что у кучи АСР эта часть просто ужасна и работать с ней сложно и приходится постоянно заниматься какой-то эквилибристикой чтобы начисления прошли как требуется.
Абонентская плата за услугу, по конкретному тарифному плану, с изменением статуса абонента при уходе баланса в минус, и просьбе абонента о доверительном платеже (допустим, 15 рублей), включает абонента на 10 дней до реальной оплаты АП. Сколько таблиц нужно добавить в Вашу схему, по Вашему мнению?
В пределах 10
Если я правильно понимаю, то в нормальной структуре это одна таблица (и то, если ничего похожего еще нет), с данными документа типа «Доверительный платеж», который дебетует активный счет «долг клиента А» и кредитует пассивный счет «абонентский счет клиента А». Изменение статуса мне не очень понятно зачем, но это отдельное поле у клиента.
Если я правильно понимаю, то в нормальной структуре это одна таблица (и то, если ничего похожего еще нет)
Я про комплекс говорю из тарифного плана, статуса клиента, доверительного платежа, а так же связок с абонентскими платами и услугами входящими в тарифный план. Ну и да «доверительный платеж» не должен проводиться как документ и как-то влиять на баланс клиента. Это отдельная сущность которая просто учитывается при начислении и включении клиента. Так-как это не настоящие деньги и проводку по ним делать точно не стоит.
Изменение статуса мне не очень понятно зачем, но это отдельное поле у клиента.
Вообще не поле. А отдельная таблица состояний. Это требуется для корректного начисления и перерасчета услуги.
А почему собственно деньги «ненастоящие»?
Вполне себе настоящие. Просто клиент их у нас «одолжил».
Вывести из системы их нельзя, пока не погасишь долг. Но потратить можно как и обычные деньги на счету.
Собственно чтобы не городить специфичные механизмы «активации пользователя», «особых статусов» и прочего проще считать их как отдельный вид пополнения. А дальше включается обычный механизм продления услуг и т.п.
Да, ваш план счетов ограничивает вас с учетом долга. Но Вы можете его учесть в отдельной таблице, аналогично с деньгами на счету клиента. Просто больше таблиц, ничего страшного.
Документ же нужен не только для учета, но еще и как основание для движения при возврате денег.
Например не сложно будет сделать такую логику работы такой услуги:
доверительный платеж может быть на любую сумму в пределах 10% от суммы которую клиент уже успел нам заплатить за прошлые периоды.
При этом возвращать клиенту нужно будет на 10% больше.
Гасится долг либо при следующем пополнении счета, либо если пополнения не было, то через 15 дней после платежа, сумма вычитается со счета клиента, делая его отрицательным.
Повторный доверительный платеж без погашения прошлых невозможен.
Вполне себе настоящие. Просто клиент их у нас «одолжил».
Вывести из системы их нельзя, пока не погасишь долг. Но потратить можно как и обычные деньги на счету.
Собственно чтобы не городить специфичные механизмы «активации пользователя», «особых статусов» и прочего проще считать их как отдельный вид пополнения. А дальше включается обычный механизм продления услуг и т.п.
Да, ваш план счетов ограничивает вас с учетом долга. Но Вы можете его учесть в отдельной таблице, аналогично с деньгами на счету клиента. Просто больше таблиц, ничего страшного.
Документ же нужен не только для учета, но еще и как основание для движения при возврате денег.
Например не сложно будет сделать такую логику работы такой услуги:
доверительный платеж может быть на любую сумму в пределах 10% от суммы которую клиент уже успел нам заплатить за прошлые периоды.
При этом возвращать клиенту нужно будет на 10% больше.
Гасится долг либо при следующем пополнении счета, либо если пополнения не было, то через 15 дней после платежа, сумма вычитается со счета клиента, делая его отрицательным.
Повторный доверительный платеж без погашения прошлых невозможен.
А почему собственно деньги «ненастоящие»?
Вполне себе настоящие. Просто клиент их у нас «одолжил».
Ненастоящие. Настоящие выражены в начислении и являются основанием к примеру подать на клиента в суд в случае если он не погасит задолженность. А вот доверенный платеж нельзя взыскать с клиента. Плюс придется городить отдельный механизм чтобы у нас нигде это не учитывалось в отчетах. И это сложнее для понимания клиентом. У меня вообще скажем негативное отношение к таким доверительным платежам, так-как как правило их механизм сводится к тому чтобы сдвинуть сроки оплаты. И в таком случае проще сделать другой механизм который позволял бы клиенту работать в кредит на то количество дней которое он запросил.
Собственно чтобы не городить специфичные механизмы «активации пользователя», «особых статусов» и прочего проще считать их как отдельный вид пополнения. А дальше включается обычный механизм продления услуг и т.п.
Фишка в том что другие статусы все равно будут :)
доверительный платеж может быть на любую сумму в пределах 10% от суммы которую клиент уже успел нам заплатить за прошлые периоды.
При этом возвращать клиенту нужно будет на 10% больше.
Гасится долг либо при следующем пополнении счета, либо если пополнения не было, то через 15 дней после платежа, сумма вычитается со счета клиента, делая его отрицательным.
Повторный доверительный платеж без погашения прошлых невозможен.
Скажем никто не мешает делать это и без отображения доверительного платежа клиенту. И да заплатить больше не получится, так-как начисление за услуги идет отдельно.
Про доверительный платёж. По сути это кредитование клиента.
Если у вас по договору авансовая система расчёта, то да, в суде не взыщите.
А если кредитная, то очень даже (правда из-за размера суммы малорентабельно да и имиджевые потери).
Так что с одной стороны — это не «ненастоящие деньги», с другой — нет никакого счёта «долг клиента».
Есть субсчёт для учёта расчётов с Васей Пупкиным, открытый к 62 счёту. И этот субсчёт может иметь как дебетовое, так и кредитовое сальдо.
Если у вас по договору авансовая система расчёта, то да, в суде не взыщите.
А если кредитная, то очень даже (правда из-за размера суммы малорентабельно да и имиджевые потери).
Так что с одной стороны — это не «ненастоящие деньги», с другой — нет никакого счёта «долг клиента».
Есть субсчёт для учёта расчётов с Васей Пупкиным, открытый к 62 счёту. И этот субсчёт может иметь как дебетовое, так и кредитовое сальдо.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Типовая схема биллинга