logo
logo

Форум Процент при переводе с одного счета на другой

создать новую тему раскрыть все
Процент при переводе с одного счета на другой Валентин 01/03/2012 18:53 #написать ответ
Предлагаю, добавить возможность указания процента при переводе с одного счета на другой. Причем желательно, чтоб был выбор - указывать либо реальную сумму, либо процент.
Пример:
У меня карточка банка "A"  и два счета: "наличные" и "карта".
Если я снимаю деньги в банкомате банка "А" то это мне ничего не стоит.
Если я снимаю в банкомате банка "B", то это стоит мне 0,5 уе., а если в банкомате банка "С", то 3% от суммы.
Можно конечно добавить статью расхода и проводить это дело отдельно, но было бы удобнее, чтоб такого рода графа появлялась при вводе самого перевода.
Спасибо.
А что по-вашему есть этот процент? vovchik23 01/03/2012 19:37 #написать ответ
Как по-мне так это и есть операция расхода, т.к. часть ваших денег тратится. Перевод же это не более чем перекладывание денег из одного кармана в другой, при котором денег у вас не становится ни больше, ни меньше.
 
Согласен, неудобно, что надо две операции делать. Но удобнее станет, лишь тогда, когда Дервиш сделает сплиты, т.е. не скоро
Это расход который не может существовать без самого факта перевода Валентин 01/03/2012 19:54 #написать ответ
Сомневаюсь, что будет сплит позволяющий часть денег записать как расход, а часть перевести на другой счет.
Я не против вводить процент за перевод отдельной статьей - сейчас так и делаю. Но получается, что одна операция - снятие денег с карточки требует двух действий - введение самого перевода и введение затрат на его осуществление.
Я же просто предлагаю, чтоб при выборе опции перевода, была графа, куда можно было-бы ввести этот процент.
Согласен что vovchik23 01/03/2012 20:25 #написать ответ
это накладно, но если в диалоге операции перевода будет еще и графа для процента расхода, то это уже не перевод будет.
Сплиты же, это как бы и есть это самое упрощение, когда одной операцией можно
часть денег записать как расход, а часть перевести на другой счет
Давай подождем, что скажет автор програмы на мое предложение... (-) Валентин 01/03/2012 20:57 #написать ответ
Конечно! :) (-) vovchik23 01/03/2012 22:58 #написать ответ
Поделюсь своими задумками на этот счет. Dervish 02/03/2012 12:17 #написать ответ
Сплиты обсуждались довольно давно. И у меня есть желание их сделать, вот только пока еще я не приступил к этому. Впрочем, о сроках чуть ниже.
 
Многие учетные программы трактуют сплит просто как возможность разделить чек из магазина по разным статьям. Молоко в одну кучку (статью), хлеб - в другую. Но мне хотелось бы реализовать более широкое понимание сплитов. Я рассматривал бы сплит как папочку, в которую входит несколько разных операций. В том числе, в одной папочке могут быть операции всех типов. То есть, в сплит запросто можно будет "положить" операцию перевода и операцию расхода. Тот самый случай, который сейчас обсуждается.
 
В общем, в сплит, как и в любую папочку, можно будет положить сколько угодно операций разных типов. Мало того, возможно, что будет полезным делать вложенные сплиты. Папочка в папочке ну и так далее. Правда, это еще открытый для меня вопрос, тут его нужно будет обдумать.
 
Если на закладке операций фильтры настроены таким образом, что из сплита под эти фильтры попадает всего одна операция, возможно, что строчка с папочкой вообще показываться не будет. А вот если под фильтры попадают несколько операций из одного сплита, то они будут показываться в раскрываемой папочке. Ну и для этой папочке можно будет сделать показ итоговых сумм (согласующихся с фильтром).
 
Основное применение для таких сплитов мне видится именно в реализации вот таких сложных проводок, которые должны выполняться одновременно. Ну и разбить чек на молоко-хлеб, но это вторично уже.
 
Поскольку, на мой взгляд, общей болезнью учетных программ является уйма времени, требующаяся на ввод данных, мне показалось, что можно использовать сплиты для усовершенствования ввода операций.
 
С одной стороны, на ввод каждой операции сейчас уходит довольно много времени: даты, классификаторы, суммы. С другой стороны, не знаю как вы, а я все время ловлю себя на мысли, что вводить, по сути, приходится как правило одно и то же. Отсюда родилась идея: реализовать шаблоны для ввода операций. Макрос, по моей задумке, это "почти заполненный" сплит. Это группа операций, в которых не проставлены какие-то реквизиты. Например, дата сплита. Или суммы. При этом, крайне необходим механизм, позволяющий пересчитывать такие шаблоны в момент исполнения.
 
Тогда будет допустим примерно такой сценарий ввода операции в программу: пользователь выбирает по названиям из заранее подготовленного списка шаблонов нужный ему. Двойной клик на нужном шаблоне и на экране появляется окно, в котором присутствуют только не заполненные в шаблоне поля (или заполненные, но специально помеченные для показа). Пользователь заполняет недостающие данные. Если там не указана сумма, то вводит эту сумму. Когда пользователь нажимает ОК, AbilityCash вычисляет все суммы операций по введенной сумме. Например, может автоматически посчитать комиссии за выполнение операций.
В копилку мыслей. Илья 02/03/2012 13:02 #написать ответ
В SAP, в заказах, примерно похожее строение: есть заголовок заказа (описываются общие данные), есть позиции (например закупаемые материалы\услуги), к позиции есть ещё более детальные таблицы (графики поставок, контировки, условия расчёта цены и т.п.). Есть куча настроек и мест в коде для расширения функционала, которые реализовываются в рамках требуемого процесса (т.е. заказ - один из объектов\частей этого процесса).
Если интересно, можно пообщаться.
Интересно-то интересно... Dervish 02/03/2012 13:49 #написать ответ
Да вот я даже то что задумал не успеваю делать...
Очень интересные задумки Валентин 02/03/2012 21:26 #написать ответ
Спасибо за развернутый ответ
по поводу сплитов tim_d 18/03/2012 02:28 #написать ответ
уважаемый автор обмолвился, что возможно коснется темы сроков. Автор, коснитесь пожалуйста
 
З.Ы. при более-менее среднем учете сплитов начинает нехватать как воздуха
По срокам такой доработки могу... Dervish 18/03/2012 14:01 #написать ответ
...отметить два момента. Во-первых, мне всегда очень трудно давать прогнозы по срокам выхода сборок, в том числе и потому, что, как я уже говорил, я занимаюсь программой в свое свободное время. А во-вторых, эта доработка довольно нетривиальная, она потребует изменения структуры базы данных, что, в свою очередь, приведет к переработке уймы кода... Кроме того, интерфейс, безусловно, должен претерпеть свои изменения...  В общем, не думаю, что это будет быстрое дело.
 
З.Ы. Мой учет более средний и не могу сказать, что сплитов не хватает как воздуха.
такую программу надо (-) Bubot во-во!!! 22/03/2012 15:48 #написать ответ
Мне кажеться Doc.X 18/03/2012 17:25 #написать ответ
Мне кажется было бы удобно сделать три поля при переводе с одного счёта на другой такие же как при переводе с одной валюты на другую. Сумма списания, сумма зачисления.
Тогда можно будет учитывать комиссию хотя бы так.
Комиссия является расходом Amundsen 18/03/2012 19:01 #написать ответ
и ее учет должен быть соотетственно расходной операцией. Вы же транспортные расходы вносите расходом? Вот и комиссия по сути есть оплата транспорта ваших средств.
На каждый перевод делать дополнительно и расход не удобно. Doc.X 18/03/2012 20:02 #написать ответ
У меня в программе счета WebMoney там с каждой транзакции снимается 0.8%
Как появятся сплиты vovchik23 18/03/2012 21:17 #написать ответ
все ваши подобные проблемы станут неактуальны.
совершенно верно и справедливо tim_d 21/03/2012 12:32 #написать ответ
такая ситуация возникает сплошь и рядом: при переводе из одного вида денег в другой взимается комиссия, при обналичивании - тоже. оплата через банк - банк берет комиссию. "вознаграждение" при возврате долга за предоставление этого самого долга также является частью операции. тысячи их (примеров). конечно это решаемо отдельными операциями, вроде: перевод + расход (комиссия). но если таких операций много и совершаются они регулярно, напр, ежемесячно и если надо вести несколько баз - то это катастрофа. так бы создать один повторяющийся сплит и проблема решена...
Неудобно спать на потолке... :) z13 21/03/2012 15:43 #написать ответ
У меня по разным операциям совершенно разные проценты, которые регулярно меняются.
Потом, зачем мне видеть постоянно на экране то, что я использую в  1% случаев?
Так что, выбирая из: добавить поле или добавить сплит\набор операций, более перспективное будет второе.
конечно только сплит tim_d 21/03/2012 16:26 #написать ответ
конечно только сплит правильно и элегантно решит вставшую задачу. хотя в общем случае вариант с полем должен быть технически легче реализуем
а в программе можно делать прекрасные шаблоны (-) Bubot опа 22/03/2012 15:55 #написать ответ
мой вариант куверти3 23/03/2012 11:42 #написать ответ
Как стратег, видящий бой со стороны, не могу не умолчать свой вариант по сплиту.
На поле ввода операций делаем кнопу "сплит". Что такое сплит в моем понимании? Когда надо внести несколько позиций чека и/или комиссию банка/оператора. Остальное в частном порядке спокойно делается обычной унарной проводкой.
Так вот нажимаем мы сплит, и там выходит такое достаточное большое отдельное окно, в котором либо фиксированное кол-во  строк, либо программка сначала спросит, сколько строк показать/создать в сплите.
В этом окне одна дата проводки (хотя можно и к каждой строке, тогда выбранная дата в одной строке автоматом копируется во все остальные, но после этого в каждой отдельной строке дату можно поправить, + чуть позже).
В каждой строке - сумма, классификатор, примечание.
Сначала мы массово меняем поля, т.е. выбором классификатора в одной строке задаём копирование автоматом в другие строки.
+чуть позже: т.е. концепция первичного задания массового изменения, но затем частного изменения в конкретной позиции. можно при изменении данных в уже заполненной автоматом позиции наряду с ячейкой выбора параметра ставить две радиокнопки: "во всех ячейках" и "только в этой ячейке", дефолт стоит "только в этой ячейке".
Если мы таким образом зададим параметры в первой допустим строке и они скопируются в остальные поля, то останется лишь расставить суммы (это единственное поле, которое не ставится автоматом). Тогда, если я вбиваю чек из гипермаркета с 121 строками, то смогу выбрать сначала массовое значение классификатора (допустим Статья - Еда, Агент - Метро и т.п) но затем, если среди продуктов затерялся пакет и стиральный порошок, я частным порядком изменю в нужной строке Еду на Хозрасходы. Если была операция, допустим, безналом, то если сплит идет по квартплате, то можно внести, допустим, строки по каждому виду коммунальной услуги и содержанию и ремонту жилья, как в "жировке", и плюс одна строка будет с заменой Агент - ТСЖ (который вероятно будет в сплите массово внесен) на Агент - Банк с указанием комиссии в рублях (считаю, не надо автоматом % выставлять для расчета, для учетной политики лучше оставить ручной ввод в валюте учета),  и также Статья - Коммуналка заменится  на Статья - Комиссия банка
да зажег! (-) Bubot опа да зажег! 23/03/2012 12:19 #написать ответ
отвлекли, продолжу куверти3 23/03/2012 12:22 #написать ответ
Итак, у нас сформировано отдельным окном поле операций, все классификаторы и суммы расставлены. Пусть это заполняется как отдельная временная таблица в БД (тут САПеры есть, поймут).
Как только нажимаем кнопу "Выполнить проводки", у нас из этой одной таблицы записи так и формируются по одной в БД. Т.е., сама БД так и растёт только по кол-ву строк, но не таблиц.
Вы спросите, а как поднять сплит, если надо будет изменить его, или подсмотреть, или что-то? Делаем скрытое поле с уникальным идентификатором, определяющим данный сплит (формируется либо в начале ввода, либо после кнопки Выполнить). Тогда тут должен быть выбор: мы меняем впоследствии конкретную строку либо только из БД (общего списка операций), либо только при условии редактировании сплита (а это значит, что надо тратить производительность на то, чтобы по скрытому полю "поднять" все строки и зацепить в экранную форму), либо оба варианта (на выбор оператора).
Вывод сплитов может подразумевать одновременный вывод нескольких сплитов для чтения, редактирования на экран в виде экранных форм, возможность копирования и т.п.
Об отражении сплитов в списке операций.
Тут я выше заметил, что т.к. БД и должна быть одна с минимумом изменений структуры, то, если мы пишем операции как раздельные строки в БД, то они так и  отразятся. С Другой стороны, можно чекбоксом или радиокнопкой задавать параметр отображения данного сплита в списке операций: одной строкой, или построчно. Если выбор - первое, то сплит суммируется и общей суммой показывается, но тогда, если там одинаково заполненные классификаторы, то будет полноценная строка, а если разные? Если в строках разные (Статьи, Агенты и т.п.), то по умолчанию сумму можно показывать, заполняя соответствующие строки ничем или значением "Сплит". Также можно отдельную пиктограммку, как для "замочка".
Суммы в сплите могут быть как с плюсом, так и с минусом. Зависит от учетной политики, либо после реализации сплитов необходимо будет сделать отдельные пояснения. Допустим, есть статья Экономия, и я не неё собираю сумму бонусов и скидок. Тогда, при покупке в аптеке по карточке постоянного клиента, скидка отразится отдельной строкой в чеке (как правило), это приведёт к формированию расходных операций по Статье Лекарства и Витамины в основной массе строк сплита, и отдельно - приходная строка по зачислению Экономии.
Также есть над чем подумать в части порядка строк в сплите, после его формирования и записи в БД (тоже м.б. скрытым  полем БД).
Сплитом можно делать и другие сопутствующие операции: если ведётся учёт бензина и километраж (ну а вдруг). Тогда сопутствующие операции могут быть как перевод рублей в валюту Литры на счёт Бензин, и далее, в этом же сплите, перевод Литров в Километры на счёт Пробег. Тогда можно отдельно задействовать дополнительные замудрённые отчетности, если неохота просто списать денег за заправку сразу в рублях в Расход.
Извините, если занудно и долго.
Сплиты - непростая задача, если делать старательно. Dervish 24/03/2012 00:23 #написать ответ
Как это ни странно, вначале мне хотелось бы сказать пару слов о том, как сплиты должны показываться на странице операций. Точнее, как я это себе представляю сейчас:
 
Сплит на странице операций мне видится как раскрываемая папочка. Можно кликнуть на плюсик и увидеть все операции, входящие в сплит. Но даже если он свернут, то в строке, в которой рисуется эта самая папочка, должно быть показано: (а) дата сплита, (б) общая сумма изменения остатка по просматриваемому счету, (в) остаток по этому счету после выполнения сплита и (г) примечание к сплиту. То есть, строка будет выглядеть примерно как операция, только в ней не будут указаны классификаторы.
 
Самый спорный для меня момент касался пункта (а), даты сплита. Я долго думал, следует ли вводить ограничение на то, что все операции в сплите должны относиться к одной дате. И таки пришел к выводу, что да, должны. И вот почему: с одной стороны, те примеры сплитов, которые приводились в форуме, так или иначе сводились к двум случаям - кассовому чеку и снятию наличных в банкомате с удержанием комиссии. И те и другие операции выполняются одномоментно. Я попробовал придумать примеры сплитов, которые выполнялись бы в различные моменты времени и понял, что у меня не получается это сделать.
 
С другой стороны, если разрешить помещать в сплит операции с разными датами, то в этом случае я не смогу "собрать" в одну папку все операции сплита при самом употребительном порядке сортировки: по дате.
 
Итак, для меня стало понятно, что у всех операций, входящих в сплит, дата (и время) должна быть единой. Как следствие, повторение можно будет указывать только для всего сплита, но никак не для отдельных операций, входящих в сплит.
 
Наверное, еще стоит сделать общий комментарий к сплиту, помимо возможных комментариев к каждой операции, входящей в сплит.
 
Мне не совсем понятно, как именно показывать сплиты при сортировке, отличной от сортировки по дате, например, при сортировке по статьям. Похоже, в этом случае придется показывать только сами операции, без включающей их "папочки".
 
Впрочем, я отвлекся. Я затеял этот разговор потому что прежде чем придумывать механизмы ввода сплитов нужно понимать, какие данные в сплите будут общими для всего сплита, а какие - индивидуальными.
 
Теперь о предложении уважаемого Куверти.
 
Если честно, мне уже сейчас не нравится то, что для ввода операции на экране появляется диалоговое окно. И, похоже, не мне одному, иначе не появлялись бы предложения снять признак модальности с окна ввода операций. Что можно сделать с диалогом ввода операции? Я вижу три варианта:
 
- снять признак модальности;
- разрешить ввод и редактирование операций по месту, прямо в списке операций;
- сделать "выноску" внизу страницы операций, в которой показывать все данные о текущей выбранной операции и заодно разрешить создавать новые операции прямо в этих полях. Так довольно давно сделано в MS Money.
 
Но совершенно точно мне не понравится если при вводе сплита на экране будет появляться огромное окно со списком, в котором каждая операция, входящая в сплит будет занимать по отдельной строчке. Не знаю, правильно ли я понял ваши предложения, если это именно то, что предлагаете вы, то мне представляется, что это крайне неудачное решение. Хотя бы потому, что из-за этого окна ничего будет не видно. Все операции придется вводить вслепую.
 
Все это сугубо имхо и для дальнейшего обсуждения.
ИМХО Amundsen 24/03/2012 11:28 #написать ответ
Сплит на странице операций мне видится как раскрываемая папочка.

С т.з. единобразия папочка будет лишней: интерфейсное решение д.б. аналогично остальным деревьям в программе.
 
(б) общая сумма изменения остатка по просматриваемому счету, (в) остаток по этому счету после выполнения сплита

Я очень расчитываю, что сплит смогут составлять разные счета. Пример: начисление бонусных баллов при покупках, коммунальные платежи.
 
Я попробовал придумать примеры сплитов, которые выполнялись бы в различные моменты времени и понял, что у меня не получается это сделать.
Я помогу : Приход средств и его распределение по нескольким счетам в разных банках включая зависимые платежи и т.п. Этот набор связанных и регулярных транзакций может занимать несколько дней. Но я не настаиваю, вариант с единой датой безусловно проще в реализации.
 
Мне не совсем понятно, как именно показывать сплиты при сортировке, отличной от сортировки по дате

Сплит по сути есть группировка связанных операций, поэтому можно не изобретать велосипед который вы давно сделали: достаточно ввести поле "номер чека" и группировать по нему. Однако, следует учитывать дополнительные возможности, которые может дать такая группировка, о них говорил Куверти: ряд параметров для группы можно задавать единожды, я лишь хотел бы добавить возможность разносить скидки (или комиссии) по проводкам группы.
Вера на веру, имхо на имхо. :) Dervish 25/03/2012 00:37 #написать ответ
С т.з. единобразия папочка будет лишней: интерфейсное решение д.б. аналогично остальным деревьям в программе.

 
Мне казалось, что папочка как интерфейсное решение, это самое аналогичное остальным деревьям в программе. Папка счетов - название само за себя говорит. Классификаторы вообще все только на папках построены.
 
Я очень расчитываю, что сплит смогут составлять разные счета. Пример: начисление бонусных баллов при покупках, коммунальные платежи.

 
Так и надо делать. Не должно быть ограничений ни на виды операций (приходы, расходы, переводы, остатки) ни на количество счетов, используемых в сплите. Любые операции, любые счета.
 
Приход средств и его распределение по нескольким счетам в разных банках включая зависимые платежи и т.п. Этот набор связанных и регулярных транзакций может занимать несколько дней. Но я не настаиваю, вариант с единой датой безусловно проще в реализации.

 
Нет, немного не то. Эдак можно придти к выводу (вполне справедливому кстати), что вообще все операции в учете взаимосвязаны. Но из этого не следует, что их нужно заключать в единый сплит.
 
Хорошо, немного переформулирую: сплит, это группа операций, выполняемая единовременно, в один момент времени. Так подойдет?
Про папочки Amundsen 25/03/2012 01:03 #написать ответ
Я тогда подумал, что речь идет о графическом изображении папочки, против которого и решил возразить.
 
сплит, это группа операций, выполняемая единовременно, в один момент времени. Так подойдет?

Подойдет разумеется. Но тот мой пример характерен регулярностью и под него просто просится шаблон, который, в свою очередь, удобно реализуется сплитом.
Ещё пара слов о сплитах Куверти3 24/03/2012 12:04 #написать ответ
О разной дате.
В момент покупки по карте может происходить вот что: сумма лишь резервируется магазином (и банком, если комиссия), но реально списывается чуть позже, на 2-3 день. Я, право, сам путался, когда сравнивал данные банковской выписки с реальными днями списания одинаковых сумм. Т.е., суммы безнала могут быть списаны в разные дни (теоретически).  Также разные даты в сплите могут дать дополнительный инструмент для учёта расходов и доходов (альтернатива) в случае учета денег "по проектам". Заводим не классификатор Проекты, а на проект - один сплит, и в нём пишем доходы и расходы.
О порядке сортировки.
Сортировка в общем случае может происходить как по одному, так и по группе полей записи ( в терминах теории БД).
Таким образом, не вижу трудности отображать в соответствующие даты только те суммы сплита, которые приходятся именно на эту дату. Также с классификаторами: не вижу трудности сортировки сплитовых строк как единичных, с подсуммированием "в плюсик" общей суммы по данному классификатору.
По правилам ввода записей.
По окну не вижу трудностей, если мы имеем чек и знаем, куда мы его хотим отнести в плане классификации учёта. Списки с датами и значениями статей также будут открываться.
Если делать, то тогда разрешить, как в  Экселе, вставку строки (т.е. предварительно мы встаём в строку с нужной датой и она по умолчанию формирует нам дату чистой следующей строки, потом правой мышкой ТЫЦ - выходит меню, в нём Добавить строки). Тогда строка будет соответствовать отображаемому виду окна операций. В ней можно сразу выводить кнопки выпадающего списка во всех полях, или только в редактируемом поле. Тогда неплохо было бы сделать функцию автоподбора значения списка, чтобы не рыскать мышкиным колесом туда-сюда. Также можно сделать либо настройку общего плана, либо поп-ап при операции добавления строки, где юзер бы указал, сколько строк добавить, и должен ли это быть сплит. В зависимости от значения радиокнопки или чекбокса, строки формируются сразу "под плюсиком" или как набор единичных независимых нескольких строк.
Еще о дате Amundsen 24/03/2012 12:39 #написать ответ
А ведь в программе есть две даты: операции и бюджетная. Одну из них можно использовать как единую (для сортировки), а другую присваивать отдельным проводкам.
 
Заводим не классификатор Проекты, а на проект - один сплит, и в нём пишем доходы и расходы.

А вот это свежая и интересная идея.
Смешались в кучу люди, кони. Dervish 25/03/2012 00:51 #написать ответ
Я бы ратовал за разделение дискуссий по (а) структуре сплитов, (б) отображению сплитов и (в) вводу сплитов.
 
В момент покупки по карте может происходить вот что: сумма лишь резервируется магазином (и банком, если комиссия), но реально списывается чуть позже, на 2-3 день.

 
Да, бывает такое и очень часто. Но лично меня совсем не парит ввести это дело двумя операциями. И, кстати, на мое интуитивное имхо, тут сплит совсем не нужен. Ну да, он может дать некую связь между платежом и взятием комиссии по этому платежу. Но опять же, эта связь будет невидима в случае выборки операций по датам (и сортировки по ним же). Ну как бы все равно не вижу смысла.
 
Также разные даты в сплите могут дать дополнительный инструмент для учёта расходов и доходов (альтернатива) в случае учета денег "по проектам".

 
Этого я просто не смог понять. Извините.
 
Заводим не классификатор Проекты, а на проект - один сплит, и в нём пишем доходы и расходы.

 
Сплит, длящийся месяцами или годами? Не могу осмыслить такое. Сплит как замена проекта? А зачем заменять проект, чем он провинился? Нет, ну как-то слишком непривычный полет фантазии, я к этому не готов.
 
По правилам ввода записей.

 
Я понял Вашу основную идею так: видеть на экране целиком весь чек и вносить в него данные не построчно, а сразу табличкой. При этом экономя на вводе классификаторов за счет подстановки в незаполненные поля нужных классификаторов.
 
Ответить на это могу так: я пока не знаю, как именно я сделаю ввод сплитов. Но, безусловно, я постараюсь сделать ввод сплитов как можно более экономным по времени и мышечным сокращениям. Или постараюсь сделать несколько вариантов ввода сплитов.
Вот-вот... z13 24/03/2012 16:36 #написать ответ
... у меня 12" экран, места лишнего не бывает.
12", это очень мало. Dervish 25/03/2012 00:53 #написать ответ
Не могу себе представить, как можно на таком экране работать. На моем ноуте 18,4 дюйма диагональ и разрешение Full HD и то временами места не хватает. А 12" вообще очень маленький экран...
 
А какое разрешение у Вашего экрана?
10 дюймов 1024на768 (-) bu 25/03/2012 10:16 #написать ответ
1366х768 (-) z13 25/03/2012 10:46 #написать ответ