Векселя это официальный документ, который отразится как дебет счета 60 у того кто вексель выдал и кредит 60 у того кто дал. Но так как это средство оплаты то эти операции будут двойными со счетами за что дан вексель. Либо реализация товаров либо услуг. Крыши Жор никогда не отражались в бухгалтерии, пока они не стали официальными ЧОП-ами Жора и К. С этого времени операции как и полагаются обычные оплаты услуг по счетам.
Забалансовые счета не используют двойную запись. Это просто памятка для вас. Создадите счет какой-то и будете туда плюсовать "мои обещания". Чтобы в любой момент видеть сколько наобещали. Когда отдадите физически деньги из кассы (с личного кошелька) с двойной записью, то дополнительно сами спишите (или автоматизируете с помощью каких-то признаков автосписания) с этого забалансового счета такую же сумму. Ну и всегда можете увидеть то самое сальдо по этому счету, чтобы знать сколько еще наобещали.
В этом случае это не регистрация свершившихся фактов и не нуждается в двойной записи. Это бюджетирование и планирование. Эта деятельность тоже автоматизируется на 1С но в бухгалтерской терминологии не нуждается. А вот когда ваше "обещание" - планируемые расходы перейдут к стадии реализации то вы отразите расход в терминах бухгалтерии.
Вы не можете кому-то пообещать и подарить 100 рублей. Это не ваши деньги, ни владельца бизнеса, ни учередителя, ни кого-то еще. Сначала вы обязаны передать эти 100 рублей себе в виде зп, вознаграждений, девидентов и т.д. Чтобы эта сумма отразилась в налогооблагаемой базе, чтобы было известно кто за эти деньги рассчитается налогами. И только после этого дарите кому и как хотите. А "пообещал" породит такие вопросы у налоговой в плане отмывки или прямого укрывательства от налогов что будете расхлебывать несколько лет.
Потому что практически нет задач в учете которые можно сделать в несколько потоков. Разве что запустить где-то формирования длительного отчета. А все основные действия обязаны проводиться атомарно.
А распаралелливание в большей части берет на себя сервер БД. Когда разбивает большие запросы на потоки. Клиент в итоге получает единый набор данных который выводится уже в UI потоке, который и так везде, в любых системах, один.
Это не удобно, это не продуктивно. Доказательство самое простое - 1С-ник за час набросает систему с формами справочников, формами списков этих самых справочников, пару документов и пару отчетов. На что у команды пишущих текстом уйдет пара недель. Это не выдумка из головы. Чтобы получить первичный сертификат 1С Специалист за 4 часа нужно сделать фактически полноценную систему учета.
А по поводу "новинок" делать GUI текстом. Я год как хобби делал себе плеер на флуттере, пока окончательно не утонул в "удобных" портянка виджетов. В итоге плюнул на него и начал сначала на WinUI.
Нигде не взлетели потому что программистам нужны сверх кастомизируемые контролы. Возможность сделать что-то отличающееся от тысяч конкурентов. 1С не для этого, любое отклонение от принятого стандарта это жирный минус. Нужно десятки раз сначала подумать нужно ли делать хоть что-то нестандартное. Потому что бизнесу нужно чтобы любой новый сотрудник просто сел и работал а не выяснял а что тут в экране такое новенькое.
Но если колонка одна, много чего (типа динамики по времени) считать проще.
А когда тысяча пользователей хотят узнать какие есть товары на складе а с другой стороны сотня бухгалтеров хочет внести операции с кассой все зависнут в ожидании блокировок?
Потому и гроссбухи были разные, кому то нельзя знать сколько есть в кассе и на счетах, кому то нет смысла ждать пока заполнят кассу и банк, его интересуют данные совсем из других книг. Так и сейчас не все операции с кассами и счетами относятся к товарам. Зачем блокировать всю систему когда можно работать только со своей частью.
Двойная запись это обычная физика - закон сохранения энергии. Если в одном месте убыло то в другом обязательно должно прибыть. Ни больше ни меньше. Если деньги убыли/прибыли то эта же сумма обязана появиться/исчезнуть в другом месте. Деньги еще не отдали, но товар появился - значит на эту сумму обязана увеличиться задолженность перед поставщиками. Отдали на благотворительность - значит увеличиваются Прочие расходы. Вот и все, ничего сложного. Просто стандартизированные названия.
И да, от русских команд в 1С до сих пор кровь из глаз
А вот это кстати зря. 1С-ники пишут на том языке на котором думаю, на котором они видят сны в конце концов. Если вам приходилось изучать иностранный язык по настоящему то должны были проходить определенную границу, когда мозг переключается и начинаешь думать на другом языке. Пока такая граница не пройдена человек не знает языка, постоянно думает о составе предложения, предлогах, окончаниях слов и т.д.
Подсознание любого программиста, пишущего на не на родном ему языке, постоянно переводит иностранные слова, транслирует их в свою систему мышления. Даже если это явно и не кажется проблемой. В медицине это называется ... шизофренией. У 1С-ников мозг этим не занимается, он работает в естественном для него режиме, в своем родном пространстве понятий.
Так что пишущий на том же языке на котором думает всегда будет производительней. Как вы думаете что думают англоязычные программисты глядя на код написанный на их родном языке.
Начиная от "сальдо" которое человеку долго считать - компутеру тоже это долго считать и все базы хранят и пересчитывают это сальдо с каждой операцией. Обычно это называют типа materialized. В 1С это называют итогами. Но суть то не меняется это все то же самое сальдо.
Дебет с кредитом, ну опять же назовите это по другому, плюс/минус значение. Суть то от этого не поменяется.
Двойная запись - ну так это основа основ. Есть ваши деньги и есть ваши покупки. Не важно где это в базе данных, в двух микросервисах или любом другом месте. Факт в том что операция всегда должна одновременно и на одну и ту же сумму изменять их. Взять деньги с вашего счета и точно на эту же сумму положить в ваши покупки. Ни сотой копейки разницы быть не может. Хотите обзывайте транзакцией, хотите атомарной операцией, но вот бухгалтера это уже несколько столетий называют двойной записью.
Не изменилось абсолютно ничего. Только вот названия почему то стало сложно запоминать и осмыслять :)
В книге сложно исправить запись, в компьютере наоборот.
Вот именно по этому и остаются бухгалтера, которые несут персональную ответственность за цифры в компьютере. Кстати в западных системах принципиально запрещено исправление записей. Можете исправить ошибку такой же отрицательной операцией (сторно). Но однажды внесенная операция остается свидетельством ошибки или попытки обмана.
Вы ошибаетесь. Бухгалтер это в первую очередь тот кто соберет бумажки с подписью, которая означает что вот конкретно этот человек взял ответственность за деньги/товары/услуги на себя и распишется в итоге своей собственной ответственностью за все операции сам.
Мир он таки далек от розовых фантазий за экраном и отвечать/сидеть за ошибки придется не виртуально.
Ну вот такие вот "эксперты". Начиная с SDK 32 можно использовать Java 11. А с SDK 34 уже Java 17. И это не зависит от minSdk, главное compileSdk, которая по умолчанию сейчас у новых проектов ставится 34.
Т.е. фактически сейчас для Android пишут на Java 17. А в SDK 36 планируется синхронизация с актуальной Java 21.
Я решил это с таблицы сравнения из статьи. Соберется "мало мальский" проект за секунду или за 0.1 совершенно не важно. А то что больше 20000 строк и вроде уже требует ощутимых 5 секунд замечательно усекается флагом --incremental в tsconfig.json. Сомневаюсь что кто-то реально сначала добавит новые 20000 строк и только потом повторно соберет проект.
При этом в той же таблице 18 тыс.строк собираются за 5 секунд а 104 тысячи собираются за 6. Хотя думалось бы что должны в 5 раз дольше собираться. Т.е. проблемы медленной сборки ни всегда и не везде. А есть какая-то проблемная область которая у Вас допустим может и не использоваться. И новый компилятор вообще никак не повлияет на ваш проект.
Я не против новых идей, новых реализаций. Но хотелось бы ясности - не язык меняется а инструментарий.
Зачем этот кликбейт "в 10 раз быстрее". Сам TypeScript не станет ни быстрее ни лучше. Он так и останется сахаром над JavaScript. Быстрее станет сборка проекта. До которой 99% пользователям абсолютно все равно. Пока настрочат 1.5 млн. строк кода уже столько поменяется.
Если GUI на JavaFX почему не использовали компиляцию в натив через GraalVM? плагин gluonfx (есть mvn есть gradle версии) дают вроде элементарный способ: mvn gluonfx:build и на выходе получается полностью самодостаточный нативный исполняемый файл.
Вроде даже позволяет мобильные apk и что-то там для яблок собирать. Но это я не пробовал. А вот для win и linux собирает очень шустрые образы. Ресурсов потребляют заметно меньше чем то-же самое запущенное в виде jar-а.
С книгой пример не очень удачный. А вдруг это сборник с десятком авторов да еще и парой десятков жанров. Ну да это мелочь.Было бы неплохо намекнуть что иногда можно и даже нужно отойти от жесткой привязки к инструментам.
Если есть много ко многому, к примеру books - book_authors - authors. То можно одним запросом сразу выбрать данные о книге и его авторах в стандратной json строке. И объект можно сразу собирать целиком. Пример в нотации SQLite:
Векселя это официальный документ, который отразится как дебет счета 60 у того кто вексель выдал и кредит 60 у того кто дал. Но так как это средство оплаты то эти операции будут двойными со счетами за что дан вексель. Либо реализация товаров либо услуг. Крыши Жор никогда не отражались в бухгалтерии, пока они не стали официальными ЧОП-ами Жора и К. С этого времени операции как и полагаются обычные оплаты услуг по счетам.
Забалансовые счета не используют двойную запись. Это просто памятка для вас. Создадите счет какой-то и будете туда плюсовать "мои обещания". Чтобы в любой момент видеть сколько наобещали. Когда отдадите физически деньги из кассы (с личного кошелька) с двойной записью, то дополнительно сами спишите (или автоматизируете с помощью каких-то признаков автосписания) с этого забалансового счета такую же сумму. Ну и всегда можете увидеть то самое сальдо по этому счету, чтобы знать сколько еще наобещали.
Нет. Вы можете создать так называемый "забалансовый счет". Но это только чтобы вести заметки для себя. На таких счетах не ведут двойную запись.
В этом случае это не регистрация свершившихся фактов и не нуждается в двойной записи. Это бюджетирование и планирование. Эта деятельность тоже автоматизируется на 1С но в бухгалтерской терминологии не нуждается. А вот когда ваше "обещание" - планируемые расходы перейдут к стадии реализации то вы отразите расход в терминах бухгалтерии.
Вы не можете кому-то пообещать и подарить 100 рублей. Это не ваши деньги, ни владельца бизнеса, ни учередителя, ни кого-то еще. Сначала вы обязаны передать эти 100 рублей себе в виде зп, вознаграждений, девидентов и т.д. Чтобы эта сумма отразилась в налогооблагаемой базе, чтобы было известно кто за эти деньги рассчитается налогами. И только после этого дарите кому и как хотите. А "пообещал" породит такие вопросы у налоговой в плане отмывки или прямого укрывательства от налогов что будете расхлебывать несколько лет.
Потому что практически нет задач в учете которые можно сделать в несколько потоков. Разве что запустить где-то формирования длительного отчета. А все основные действия обязаны проводиться атомарно.
А распаралелливание в большей части берет на себя сервер БД. Когда разбивает большие запросы на потоки. Клиент в итоге получает единый набор данных который выводится уже в UI потоке, который и так везде, в любых системах, один.
Это не удобно, это не продуктивно. Доказательство самое простое - 1С-ник за час набросает систему с формами справочников, формами списков этих самых справочников, пару документов и пару отчетов. На что у команды пишущих текстом уйдет пара недель. Это не выдумка из головы. Чтобы получить первичный сертификат 1С Специалист за 4 часа нужно сделать фактически полноценную систему учета.
А по поводу "новинок" делать GUI текстом. Я год как хобби делал себе плеер на флуттере, пока окончательно не утонул в "удобных" портянка виджетов. В итоге плюнул на него и начал сначала на WinUI.
Нигде не взлетели потому что программистам нужны сверх кастомизируемые контролы. Возможность сделать что-то отличающееся от тысяч конкурентов. 1С не для этого, любое отклонение от принятого стандарта это жирный минус. Нужно десятки раз сначала подумать нужно ли делать хоть что-то нестандартное. Потому что бизнесу нужно чтобы любой новый сотрудник просто сел и работал а не выяснял а что тут в экране такое новенькое.
А когда тысяча пользователей хотят узнать какие есть товары на складе а с другой стороны сотня бухгалтеров хочет внести операции с кассой все зависнут в ожидании блокировок?
Потому и гроссбухи были разные, кому то нельзя знать сколько есть в кассе и на счетах, кому то нет смысла ждать пока заполнят кассу и банк, его интересуют данные совсем из других книг. Так и сейчас не все операции с кассами и счетами относятся к товарам. Зачем блокировать всю систему когда можно работать только со своей частью.
Двойная запись это обычная физика - закон сохранения энергии. Если в одном месте убыло то в другом обязательно должно прибыть. Ни больше ни меньше. Если деньги убыли/прибыли то эта же сумма обязана появиться/исчезнуть в другом месте. Деньги еще не отдали, но товар появился - значит на эту сумму обязана увеличиться задолженность перед поставщиками. Отдали на благотворительность - значит увеличиваются Прочие расходы. Вот и все, ничего сложного. Просто стандартизированные названия.
А вот это кстати зря. 1С-ники пишут на том языке на котором думаю, на котором они видят сны в конце концов. Если вам приходилось изучать иностранный язык по настоящему то должны были проходить определенную границу, когда мозг переключается и начинаешь думать на другом языке. Пока такая граница не пройдена человек не знает языка, постоянно думает о составе предложения, предлогах, окончаниях слов и т.д.
Подсознание любого программиста, пишущего на не на родном ему языке, постоянно переводит иностранные слова, транслирует их в свою систему мышления. Даже если это явно и не кажется проблемой. В медицине это называется ... шизофренией. У 1С-ников мозг этим не занимается, он работает в естественном для него режиме, в своем родном пространстве понятий.
Так что пишущий на том же языке на котором думает всегда будет производительней. Как вы думаете что думают англоязычные программисты глядя на код написанный на их родном языке.
Вы ошибаетесь во ... всем :)
Начиная от "сальдо" которое человеку долго считать - компутеру тоже это долго считать и все базы хранят и пересчитывают это сальдо с каждой операцией. Обычно это называют типа materialized. В 1С это называют итогами. Но суть то не меняется это все то же самое сальдо.
Дебет с кредитом, ну опять же назовите это по другому, плюс/минус значение. Суть то от этого не поменяется.
Двойная запись - ну так это основа основ. Есть ваши деньги и есть ваши покупки. Не важно где это в базе данных, в двух микросервисах или любом другом месте. Факт в том что операция всегда должна одновременно и на одну и ту же сумму изменять их. Взять деньги с вашего счета и точно на эту же сумму положить в ваши покупки. Ни сотой копейки разницы быть не может. Хотите обзывайте транзакцией, хотите атомарной операцией, но вот бухгалтера это уже несколько столетий называют двойной записью.
Не изменилось абсолютно ничего. Только вот названия почему то стало сложно запоминать и осмыслять :)
Вот именно по этому и остаются бухгалтера, которые несут персональную ответственность за цифры в компьютере. Кстати в западных системах принципиально запрещено исправление записей. Можете исправить ошибку такой же отрицательной операцией (сторно). Но однажды внесенная операция остается свидетельством ошибки или попытки обмана.
Вы ошибаетесь. Бухгалтер это в первую очередь тот кто соберет бумажки с подписью, которая означает что вот конкретно этот человек взял ответственность за деньги/товары/услуги на себя и распишется в итоге своей собственной ответственностью за все операции сам.
Мир он таки далек от розовых фантазий за экраном и отвечать/сидеть за ошибки придется не виртуально.
Ну вот такие вот "эксперты". Начиная с SDK 32 можно использовать Java 11. А с SDK 34 уже Java 17. И это не зависит от minSdk, главное compileSdk, которая по умолчанию сейчас у новых проектов ставится 34.
Т.е. фактически сейчас для Android пишут на Java 17. А в SDK 36 планируется синхронизация с актуальной Java 21.
Я решил это с таблицы сравнения из статьи. Соберется "мало мальский" проект за секунду или за 0.1 совершенно не важно. А то что больше 20000 строк и вроде уже требует ощутимых 5 секунд замечательно усекается флагом --incremental в tsconfig.json. Сомневаюсь что кто-то реально сначала добавит новые 20000 строк и только потом повторно соберет проект.
При этом в той же таблице 18 тыс.строк собираются за 5 секунд а 104 тысячи собираются за 6. Хотя думалось бы что должны в 5 раз дольше собираться. Т.е. проблемы медленной сборки ни всегда и не везде. А есть какая-то проблемная область которая у Вас допустим может и не использоваться. И новый компилятор вообще никак не повлияет на ваш проект.
Я не против новых идей, новых реализаций. Но хотелось бы ясности - не язык меняется а инструментарий.
Зачем этот кликбейт "в 10 раз быстрее". Сам TypeScript не станет ни быстрее ни лучше. Он так и останется сахаром над JavaScript. Быстрее станет сборка проекта. До которой 99% пользователям абсолютно все равно. Пока настрочат 1.5 млн. строк кода уже столько поменяется.
Это фича. Некоторых (и меня кстати тоже) бесили эти узкие портянки, которые устаешь скроллить. Теперь наконец по умолчанию строка 120 символов.
Поменять на старые 80 символов можно самому:
https://dart.dev/tools/dart-format#configuring-formatter-page-width
Если GUI на JavaFX почему не использовали компиляцию в натив через GraalVM? плагин gluonfx (есть mvn есть gradle версии) дают вроде элементарный способ: mvn gluonfx:build и на выходе получается полностью самодостаточный нативный исполняемый файл.
Вроде даже позволяет мобильные apk и что-то там для яблок собирать. Но это я не пробовал. А вот для win и linux собирает очень шустрые образы. Ресурсов потребляют заметно меньше чем то-же самое запущенное в виде jar-а.
С книгой пример не очень удачный. А вдруг это сборник с десятком авторов да еще и парой десятков жанров. Ну да это мелочь.Было бы неплохо намекнуть что иногда можно и даже нужно отойти от жесткой привязки к инструментам.
Если есть много ко многому, к примеру books - book_authors - authors. То можно одним запросом сразу выбрать данные о книге и его авторах в стандратной json строке. И объект можно сразу собирать целиком. Пример в нотации SQLite:
selectb.id, b.title,(select json_group_array(json_object(a.id, a.name))frombook_authors as bajoin authors as a on a.id = ba.authorwhereba.book = b.id) as authorsJSONfrombooks b