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