|
![]() |
#1 |
Banned
|
А теперь - по существу:
Сам бухучет не отличается. Есть дебет и кредит. В конце года подводим итоги и закрываем прибыль на капитал ![]() Последний раз редактировалось EVGL; 29.06.2021 в 10:09. |
|
|
За это сообщение автора поблагодарили: Lemming (10), sukhanchik (10), gl00mie (10). |
![]() |
#2 |
Участник
|
"И это не учёт", это те самые удобства.
Бггг. ==================== я вот тут подумал, что стоит добавить еще один паттерн, общий для всех erp. как бы ни ограничивали перепроведение, но везде есть паттерн: 1. делаем первичку 2. на основании первички создаем "налоговый" учет, который допускает ручные коррекции 3. на основании "налогового" учета делаем отчеты, выгрузки и т.п. В России наиболее типичным является собственно налоговый учет, книги покупок/продаж всякие, кассовые книги, зарплатные налоги и т.п. В проклято-буржуинии всякие налоги на использование (UseTax, в стандартной Аксапте разными людьми реализовано раз 5-6), разные Intrastat, тот же XBRL В Аксапте конечно же стоит вспомнить Layer::Operational, Layer::Tax в LedgerTrans... наши локализаторы не заметили этих слоев, поскольку искренне считали, что двойного учёта на холме быть не может ![]() ![]() А такой паттерн есть везде. поэтому если самописная система будет уметь: - регистрировать операционную деятельность - рассчитывать (и перерасчитывать) затраты и вознаграждения: --- фиксированной суммой --- от остатков, --- от оборотов --- от итоговой суммы документа --- от строки документа - регистрировать рассчитанные затраты и вознаграждения в системе - предоставлять возможность вводить ручные коррекции рассчитанных затрат и вознаграждений - корректно обрабатывать такие коррекции в следующих перерасчетах и ручных коррекциях - получать итоги и обороты по зарегистрированным в системе операциям то движок можно считать сделанным в бета-версии но чтобы такой движок был востербован людьми, кроме движка должно быть многое сделано из области "привычек" и "удобств". в том числе, о чём так блестяще сказал EVGL Последний раз редактировалось mazzy; 29.06.2021 в 10:42. |
|
![]() |
#3 |
Banned
|
Цитата:
- налог на прибыль не меняет базу налога на прибыль, хотя и расход - налог на финансовые вложения взимается опосредованно банковским институтом - ряд расходов не уменьшает или уменьшает лишь частично базу налога на прибыль (например, рестораны и автомашины с классическим ДВС) В связи с этим, малые и средние, не публичные компании редко переоценивают основные средства по нескольким моделям. Хватает налоговой. |
|
![]() |
#4 |
Участник
|
|
|
![]() |
#5 |
Banned
|
|
|
![]() |
#6 |
Участник
|
|
|
![]() |
#7 |
Banned
|
Люди путают корреспонденцию счетов в плане правил и условностей ведения бухучета (манифестируется в русской "шахматке", пример: не разноси предоплату от клиента в корреспонденции со счетом доходов, не списывай сразу исходящий платеж, если он идет несколько дней и тебе / твоему аудитору это важно) и одноименную двойную запись с попарным дебетом и кредитом (экс-СССР). Так что вы поясните, что имеется в виду.
|
|
![]() |
#8 |
Участник
|
Корреспонденция счетов подразумевается в любой учетной системе для бухучета.
Я имел в виду то что в аксапте под этим имеют в виду в том виде как это переведено на русский. Т.е. делаем ли мы сразу простые проводки с однозначным дебет кредитом как в 1С или делаем сложные многострочные проводки, которые потом героически превращаем где то внутри в однострочные. Я думаю, что если делать универсальный движок, то лучше сразу простые проводки делать. Эта запись содержит больше информации и если пользователю захочется, то легко представима в виде сложной проводки просто за счет группировки. А наоборот будет гемор как с корреспонденцией в аксапте. Сложная, ресурсоемкая и неоднозначная процедура. P.S. А вообще я думаю что TC затеял безнадежное дело. Серьезные системы не пишутся силами одного разработчика. По итогу будет потерянное время и разочарование. Плюс, я думаю что программисту очень трудно нормально спроектировать удачную ERP-систему (не конкретно Lemming - у) а вообще абстрактному супер пупер программисту. Его неизбежно затянут технологические детали, понравившиеся фичи и.т.п. Нужно быть аналитиком с хорошим опытом внедрения основных модулей и неким опытом разработки тоже. Опыт внедрения не даст оторваться от реальности. Даст понимание что реально нужно заказчику а на что даже не стоит смотреть не то что тратить какой-то ресурс. Это очень важно. Иногда смотришь на целые мертворожденные куски в аксапте и грустишь на что был потрачен ресурс. Во времена дамгаардов такой фигни не было. |
|
|
За это сообщение автора поблагодарили: Lemming (5). |
![]() |
#9 |
Banned
|
Цитата:
В ряде случаев для внутреннего анализа на предприятии интересно иметь, конечно, 100 отдельно. В моей практике это налог в "фонд поддержки семьи" с выплат собственнику / директору предприятия, который сам по себе может быть предпринимателем и получать доход естественно в итоге за вычетом НДС, т.е. платеж платежу рознь. Но это экзотика. |
|
![]() |
#10 |
Участник
|
Цитата:
в любой учетной системе подразумевается двойная запись (сумма дебетов = сумме кредитов) а вот корреспонденция есть мало где. систему с корреспонденцией придумали немцы перед второй мировой войной. и передали в Союз в рамках обмена опытом. Цитата:
Цитата:
как только пытаешься добавить аналитику, так сразу возникает вопрос - к дебету или к кредиту относится аналитика. например, валюта. обрати внимание, что в одной однострочной проводке невозможно отобразить ситуацию реальной жизни, когда дебет одной валюты, а кредит в другой. ![]() придется делать несколько однострочных проводок, придумывать какие-то промежуточные счета (EVGL говорил как раз об этом) количество... в производстве нельзя отобразить расход материалов в количестве M, а приход готовой продукции в количестве N. снова через промежуточные счета а вот в многострочной проводке - тривиально. поскольку двойная запись ограничвает только суммы ![]() в современных учетных системах аналитических признаков много. и значения этих признаков могут быть разными для дебетов и кредитов. ============================ чуть сложнее: получили от поставщика товары с НДС, поставщик дал скидку. Дт Товар1 60 Дт Товар2 40 Дт НДС 20 Кт Поставщик 115 Кт Скидка 5 чтобы отобразить такую операцию, однострочных проводок нужно много. а главное, нужно решать вопросы, никакого отношения к реальной жизни не имеющие - на какой товар отнести скидку? а может увеличить оборот с поставщиком? а если от оборота считаются рибейты? и т.п. вопрос на размышление, если инвойс поставщика был в Евро, скидка в Долларах, а товар на складе учитываем в рублях, то однострочные проводки точно проще? ================== поэтому учетным системам как раз гораздо проще набрасывать движения отдельными строками. каждый модуль делает свое движение, со своими признаками. и лишь в самом конце, перед финализацией(разноской) проверяется требование двойной записи - сумма дебетов в основной валюте должна быть равна сумме кредитов в основной валюте. кроме того, в конце можно проверить и другие условия, сгруппировать однотипные проводки, расставить корреспонденцию и т.п. Последний раз редактировалось mazzy; 30.06.2021 в 14:28. |
|
|
За это сообщение автора поблагодарили: EVGL (5). |
![]() |
#11 |
Участник
|
Цитата:
даже суммирование по многострочным проводкам проще - фильтр по одному полю и сумма по другому полю - тривиальнейший select запрос. а вот суммирование по однострочным сложныее - либо надо делать два запроса и вычитать результат, либо хитро выкручиваться с функциями в списке полей ![]() |
|
Теги |
open source erp |
|
![]() |
||||
Тема | Ответов | |||
Если бы я писал ERP-систему | 23 | |||
ERP-системы — мэйнстрим или тупиковая ветвь? | 30 | |||
О причинах неудачных внедрений ERP | 4 |
|