создать новую тему раскрыть все
свернуть/развернуть ветвь Сборка 225. [Dervish 22/02/2012 20:37] # написать ответ
 
На странице загрузки программы в специальном разделе выложена 225-я сборка программы. В этой сборке реализован импорт из Excel.
 
Ну и, наверное, после исправления текущих ошибок, эту сборку можно будет считать очередным релизом программы.
 
PS. Да, тут как-то проскакивал вопрос насчет импорта дерева счетов. Сейчас все счета импортируются в виде обычного списка. В общем, я сознательно не делал импорт дерева счетов ради экономии времени.
 
уже как-то писал про такой же недочёт в старых версиях
 
...и перезалил файл на сервер. Можно обновить.
 
И новой сборки Well Огромное спасибо!
 
PS. Да, тут как-то проскакивал вопрос насчет импорта дерева счетов. Сейчас все счета импортируются в виде обычного списка. В общем, я сознательно не делал импорт дерева счетов ради экономии времени.

Да, это есть в доработках. А будет ли реализовано? Экспорт то уже есть Well
Кстати, помимо этого там еще ошибка выскакивала при импорте насчет разных валют. Тоже есть в доработках.
 
1. Экспорт в XSLX с последующим импортом в новую базу -> Теряется значение "Количество". После импорта всегда равно "1". В самом XSLX файле значения правильные.
 
2. Экспорт базы в XML с последующим импортом в новую базу -> Обнаружены ошибки (много): Дата операции указана неправильно. Импорта не происходит.
 
Ошибка отсутствует в 224 версии. Сравнил XML файлы генерируемые обоими - формат даты идентичен. Версия 224 прекрасно импортирует оба XML. Походу поломался XML импорт.
 
Кстати, первая ошибка с количеством отсутствует при XML экспорте-импорте.
 
3. При экспорте-импорте только счетов, выскакивает много ошибок "Валюта не найдена", даже если в файле, в который производится импорт эти валюты присутствуют. Приходится при экспорте также сохранять и "Валюты" - тогда ошибки не возникает.
 
Копнул глубже. Оказывается без танцев с бубном синхронизировать две схожие базы не удается. С одной стороны, при экспорте всей информации и попытке импорта в схожую базу, все классификаторы с одинаковыми именами дублируются в виде "Статья(1)", "Товары(1)", что не нужно, в принципе. С другой, если пробовать экспортировать по-отдельности, например, только операции, то импортировать их мы уже не сможем, ибо все связанные с операцией классификаторы будут отсутствовать в импортируемом файле и соответственно, даже несмотря на их присутствие в базе, программа выдаст: "Валюта не найдена", "Классификатор не найден" и пр.
 
Выходом из ситуации вижу:
- либо проверять импортируемую информацию на предмет совпадения имен классификаторов и дальше по-выбору совмещать/переименовывать их; зависимости операций и счетов же проверять не только в импортируемом файле, но и в базе, в которую происходит импорт;
- либо, что менее желательно т.к. часть классификаторов может быть утеряна, позволять импорт без проверки зависимостей у операций и счетов - тогда можно будет заранее подготовив базу с классификаторами, импортировать в нее необходимые операции или счета;
 

Не критично, но неудобно:
 
4. Шорткат Ctrl+TAB не работает при количестве страниц больше 9-ти. Баг есть и в предыдущем билде. Забавно, что c Ctrl+Shift+TAB все окей. Well
 
5. При импорте счетов, если в базе, в которую импортируют, есть такой же счет (совпадают имя и валюта), то он по-видимому не импортируется. Сужу по тому, что если в обоих счетах (тот, что уже имеется, и тот, что импортируется) есть начальный остаток, то он не меняется. Возможно хотя бы предупреждение какое-то выдавать в данном случае? Наподобие того, что появляется при разных названиях одной и той же валюты?
 
В целом, тут маленькая дилема. Простое суммирование остатков - не выход. По-сути, начальный остаток это что-то вроде операции сведения. Но даты у этой "операции" нет. Возможно, если добавить каждому счету информацию о дате его создания, то при подобном импорте можно было бы просто создавать операцию сведения на эту дату и сумму.
 
Ждите 226-ю сборку, она будет посвящена работе над ошибками, долго тянуть с ней не буду.
свернуть/развернуть ветвь Пункт 3. [Dervish 24/02/2012 00:04] # написать ответ
 
Тут вопрос, скорее, идеологический. У меня нет на него однозначного ответа.
 
Первоначально я делал импорт так, чтобы он выполнялся даже с неполными данными на входе. Допустим, импортируются только операции. В одной из операций указано название счета "RUR - Заначка", и на основании этого программа:
 
1. Проверяла наличие валюты RUR. Если ее нет в текущем файле данных, она создавалась. Небольшая проблема в том, что название неизвестно (напомню, файл импорта не содержит данные о валютах) легко обходится присвоением абстрактного названия вроде "Название валюты неизвестно", количество знаков после запятой проставляется в 2.
 
2. Проверяла наличие счета "Заначка" в этой валюте. Если счета нет, он создавался. В нем прописывался начальный остаток равный 0,00.
 
Но кое-то из моих знакомых обратил мое внимание на то, что подобный подход чреват тем, что программа, вообще говоря, может своим вольным подходом в трактовке входных данных насоздавать некорректные данные в рабочем файле. Кроме того, непонятно, как это все будет работать при дальнейшем усложнении и расширении структур данных программы.
 
В общем, я посчитал этот аргумент весомым и сделал импорт так, что он требует наличия всех исходных данных при импорте. Ну и забыл доработать экспорт. Кстати, чтобы файл - результат экспорта всегда был пригоден для импорта, можно сделать:
 
1. Вообще убрать выбор экспортируемых данных и экспортировать все данные. Всегда. Или
 
2. Оставить только возможность выбора периода для экспорта операций. Или
 
3. Оставить закладку выбора экспортируемых данных как есть, но автоматически выбирать галочки вспомогательных элементов данных. Например, если пользователь выбирает для экспорта операции, галки счетов, валют и классификаторов тут же проставляются автоматически.
 
с автоматическим добавлением в базу отсутствующих счетов, валют  и пр., несмотря на свою простоту и очевидность, мне тоже не очень импонирует. Действительно, таким образом можно насоздавать множество ненужных и случайных данных. Правда, для этого надо уж очень стараться, но все же.
 
С другой стороны, меняя диалог экспорта и урезая вполне приемлемый функционал, в виде 1-ого и 2-ого пунктов, мы лучше явно не сделаем. Экспорт всех данных часто не нужен, а возможность выбора периода, так же, как и экспортируемых счетов, просто необходима. Третий пункт - это лишь решение проблем с последующим импортом в пустую базу (я об этом тоже думал, но не написал Well. Считаю, он должен быть реализован, чтобы дальше при импорте все было корректно... НО! Решаяэту проблему с экспортом мы оставляем главную, о которой я пытался сказать!
 
Что делать, если есть необходимость синхронизации схожих баз данных? Что будет, если мы экспортируем ряд операций, даже с улучшенным функционалом экспорта (тогда ведь сохранятся и валюты, и счета, и классификаторы), а после импортируем в базу, в которой уже имеются подобные классификаторы, счета?
Все правильно, каждый раз будут создаваться все новые и новые классификаторы, по-сути, являющиеся дублями. Как бороться с этим?
 
Вот и напрашивается только одно правильное решение, а именно:
 
1. При экспорте "автоматически проставлять галки" для всех вспомогательных элементов (т.е. это и есть пункт 3), но не жестко, чтобы потом можно было опытному пользователю ненужные отключить Well
 
2. При импорте проверять не только импортируемый файл, но и базу в которую производится импорт. А дальше, если:
 
  а) В базе отсутствует классификатор/валюта с таким же именем как в импортируемом файле - делаем то же, что происходит и сейчас, создаем новый классификатор/валюту.
 
  б) В базе присутствует классификатор/валюта с таким же именем как и в импортируемом файле - либо сразу объединяем их, либо спрашиваем "Объеденить? Создать новую?"
.  Например, в базе имеется классификатор "Статья->Авто->Бензин", такой же классификатор присутствует и в импортируемом файле. Нет смысла сразу создавать новый классификатор "Статья(1)->Авто->Бензин", лучше просто оставить как и было "Статья" плюс добавить новые "подстатьи", если есть. Именно это происходит сейчас со счетами, но, в отличии от классификаторов, со счетами ситуация сложнее ибо может присутствовать остаток. Я описал эту проблему в предыдущем посте.
Разобрались теперь. Собственно все правильно работает в данном случае Well
 
  в) В базе присутствует классификатор/валюта с таким же именем как есть в "зависимостях", но в импортируемом файле есть только упоминание о нем (имеется ввиду, что, например, опытным пользователем были импортированы операции, но дополнительные галки "зависимых" счетов, валют, классификаторов были сняты). Например, была операция расхода по классификатору "Статья->Авто->Бензин" на 100р., в импортируемом файле нет классификатора "Статья", но в базе присутствует он же "Статья->Авто->Бензин"  --  Импортируем операцию игнорируя отсутствие классификатора в импортируемом файле.
 
  г) В базе, как и в импортируемом файле отсутствует классификатор/валюта с таким же именем как есть в "зависимостях" импортируемого файла. Например, список операций с отключенными "галками-зависимостями" валюта-счет-классификатор при экспорте импортируется в пустую базу. В данном случае необходимо выдавать ошибку и прекращать импорт, имхо.
 
Я сейчас перепроверил исходный код. Ну и попробовал еще раз его прогнать на моих собственных данных. В общем, дублирование с порядковым номером ("Статьи (1)") возникает только тогда, когда хотя бы что-нибудь из параметров классификаторов не совпадает. Например, классификатор в файле данных идет с разбивкой на дерево приходов и расходов, а классификатор в импортируемых данных идет с единым деревом.
 
дублирование классификаторов с номером происходит тогда, когда не совпадают параметры классификаторов! А я столько промучался, через XSLX колдовал... Well
 
Правда объединить часть баз мне удалось не сразу - постоянно выскакивала ошибка (даже не смотря на то, что я привел параметры классификаторов в порядок) и программа падала
 

 
Либо потом множество "Классификатор не используется в переводах" - опять же параметры классификаторов и имена совпадали в точности. Возникала при экспорте-импорте в XSLX, через XML все прошло корректно.
 
Но все же, через некоторое время удалось... Well
 
При различии начальных остатков по счетам было предусмотрено сообщение с предупреждением, но из-за ошибки в коде оно не срабатывало и счет молча подгружался и все. Теперь это исправлено, сообщение будет выдаваться.
 
Ждите 226-ю сборку.
 
в доработках. Их бы пофиксить, и счастью не было бы предела Well
 
С нетерпением ждем новой версии. Well