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