не знаю, у меня акциза нет.

Ну потому я Вас не сразу поняла, потому как знаю кто и чего шлёт, бывают варианты :).

Все мы дилетанты в каких-то областях . Как страшно жить...

Чего ж страшного? Это нормально.

.. По ходу дискуссии возник вопрос... Вот мы все спорим о тех или иных удобствах, использованных в современных программах. А вот интересно, у СГД есть какая-нибудь статистика по тому, сколько на сегодняшний день сдается отчетов подготовленных вручную, а сколько автоматизированных. И сколько из этих "автоматизированных" подготовлены программой... а сколько вбиты вручную в текстовой или табличный редакторы... Ведь кому-то это ВООБЩЕ не надо.. автоматизация. Кто-то продолжает скромно покупать бланочки.. заполнять их каждый месяц и носит их (отсылает по почте... не электронной). Видел 1С... в восторге. И как бухгалтер (удобств очень много) и как программист (открытая среда программирования, можно необходимое для себя сделать). НИГДЕ ПОДОБНОГО НЕ ВИДЕЛ!!! И зря вы Макссофт меня пинаете... Повидал много. И во многих сегодняшних продуктах много чего нет и не появится! Спорьте сколько угодно. Я спорить с вами не буду... лишь останусь при своем мнении.

А теперь по поводу XML... Одно дело ковыряться в форматах DBF-файлов (или прочих).. другое дело создать модуль, который парсит XML... А если программисты не соизволили оставить описание таблиц и взаимосвязь полей.. то я вообще молчу. Я уже рассказывал, что насмотрелся на подобного рода шедевры. И как, опять же, программист могу с уверенностью заявить. Многие алгоритмы просто напросто НЕОПТИМИЗИРОВАНЫ!!! Я ради интереса предлагал некоторым дать фрагменты их кода для анализа и выявления ошибок. Но видимо одно дело вешать лапшу на уши бухгалтеру, который ничего в этом не понимает и который в полной уверенности будет устанавливать драйвер коврика мышки, чем человеку который хоть что-то понимает в программировании и которому стыдно показывать свое "творчество". Оптимизация - не самоцель... а средство, позволяющее снизить риск появления ошибок! МАКССОФТ, если вы так уверены в своем детище, предлагаю вам предоставить одну копию для тестирования! Слабо? Обещаю для работы не использовать. Но уверен на 95% что вы скажете - а мне оно надо. Вон, люди пользуются и не жалуются.. необходимая поддержка осуществляется.. а что еще нужно? В общем.. отмажетесь!

А посему извините... все ваши слова, в отношении вкусностей вашего продукта, остаются словами.. Он может то.. а может это.. а еще может это. Ведь важно не только что умеет та или иная программ, но и то, КАК просто понять действие той или иной функции программы. Если для того чтобы сделать электронную декларацию нужно выполнить десятки действий.. извините... а в чем прелесть? А вот 1С (независимо от конечной конфигурации) было есть и будет средой, в которой многие действия можно самому под себя подстроить.. Есть экспорт в XML? Все.. для меня одно это уже служит огромным ЗА!!! Да я сам напишу модуль экспортирующий дальше в EDS. Главное что 1С позволяет это сделать без лишних вызовов "программистов". И как я уже сказал, если я сделаю это с ошибками.. это будут мои ошибки, но мне не надо будет платить за то что кто-то вносит исправления за мой счет! Потому что все что сегодня нужно одному, завтра понадобится многим!

МАКССОФТ. Про перенос данных... Я не имел в виду взаимодействие с банком или налоговыми органами (хотя это, в том виде как это существует сегодня, псевдоперенос..)

Одна фирма пользуется 1C, другая.. UVIS.. третья...вашим продуктом.. четвертая.. GRINS... У всех есть складской учет. Как обычно происходит.. Распечатали накладную... отдали покупателю... покупатель ввел в компьютер (руками.. через сканирование, не важно).. Но почему продавец-покупатель просто не могут передать эти данные между собой? В электронном виде. Не буду утверждать, наверняка у кого-то есть такая функция.. но мне на практике видеть не приходилось.. Почему бы разработчикам не договориться о промежуточном формате XML-файла, для того чтобы можно было экспортировать данные в другие программы.

Интересное предложение. Зачастую, при вводе новых позиций, заводить всю информацию и штрихкоды - большая проблема. Только, боюсь, дорого будет.

"Распечатали накладную... отдали покупателю... покупатель ввел в компьютер (руками.. через сканирование, не важно).. Но почему продавец-покупатель просто не могут передать эти данные между собой? В электронном виде." - потому что эта накладная при перемещении товара должна находиться у перевозчика, иметь подписи, подтверждающие получение этого товара покупателем (пока еще не электронную).

Иван имел в виду, я так поняла, что, кроме накладной, передавать информацию и в электронном виде.

Sm, речь идёт не о том, чтобы была ТОЛЬКО электронная передача данных. Накладные, счета и т.п. еще никто не отменял. Речь идёт об удобстве ввода данных с этих накладных получателем. Кстати, это очень интересно.

МАРТИНАС, ВАЛТЕРИН, спасибо за понимание, именно это я и имел в виду - использование ОДНАЖДЫ введенного. К чему заниматься мартышкиным трудом? Крупный оптовик - более мелкому.. мелкий еще более мелкому... последний розничному. И каждый сидит и тупо вбивает одно и то же. Предчувствую позицию программистов (в версии для бухгалтеров) - да вы не представляете сколько это сложностей.. у каждого товара свой внутренний код.. то да се. НЕТ! Не вижу сложностей! Запросто можно создать унифицированный справочник... Только разработчикам нужно договориться о промежуточном XML-представлении данных - и все! Создать один раз стандарт для удобства пользователей и никаких проблем. Накидать процедуру или маленький персер который разносил бы данные из XML в свою базу не составит особого труда.

Да, Иван, от "дурной" работы были бы избавлены многие. Но пока - увы...

МАКССОФТ. По поводу курсов валют... как-то я это писал... Не во всех программах есть.. хотя это очень удивляет. Попробую навскидку накидать алгоритм... в текстовом представлении.. который можно запросто перевести на любой язык программирования:

1. Вывести форму запроса валюты (параметры запроса - начальная дата, конечная дата, код валюты). Поле - конечная дата, проверяется на соответствие полю начальная дата (чтобы они соответствовали друг другу. В случае, если конечная меньше начальной.. предложить пользователю ввести новую ИЛИ!!! Заметьте ИЛИ(!!!) Указать что за начальную будет принята конечная... за конечную.. начальная!!! Поверьте, такой элементаной вещи как замена параметров диапазона нет ни в одной программе. Обычно жестко устанавливается критерий что нужно ввести дату более позднюю чем та которую ввели как начальная дата.

2. (Можно и пропустить) Проверяем, есть ли уже запрошеные валюты из указанного диапазона в нашей локальной БД.. Но это не обязательно.. хотя уменьшит нагрузку на сервер.

3. Запрос к севреру, получение ответа.

4. Запись полученных валют в БД.

Возможные ошибки - сервер не ответил, ответ получен с ошибкой, валюты не все прописались как надо. Делаем соответствующую коррекцию..

Вроде алгоритм простой.. НО!! Он сложный!!!! Почему? Объясню. Если пользователь имеет возможность обновлять курсы валют через интернет... а на dial-up сегодня уже практически никто не сидит.. ЗАЧЕМ ВООБЩЕ ПОЛЬЗОВАТЕЛЮ ГОВОРИТЬ ЧТО КУРС НЕ ВВЕДЕН??? Почему нельзя проверив что нет курса на указанную дату просто обратиться к серверу.. скачать курс и прописать его в базу.. И лишь в том случае.. если произошел сбой.. попросить ввести курс вручную!!! Просто (потому что даже не нужно вводить запрос, возникла необходимоть - скачался курс)..

Слушаю ваши замечания!

Первый вариант -алгоритм - подход программиста - есть задача, он тупо перекладывает ее в машинный код.

Второй подход - человека - я не хочу ничего вводить, я хочу ПРОСТО РАБОТАТЬ!!!

Иван. Вы про наше время и нашу страну?

КСЮША.. все вместе взятые мы составляем одно целое. Так что если обобщать и философствовать..

А вообще я про то, что люди порой создают себе сложности там, где этого вообще не надо.

МАКССОФТ. Как уже заметил.. вряд ли вы предоставите ваш продукт для анализа. Вопрос... как программист программисту. Каким образом в вашей программе реализован справочник... налоговых ставок.

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

Теперь.. Расчет, например, зарплаты. Как узнать какие налоги действуют для указанного для расчета периода? Правильно.. найти нужный диапазон! Вы как программист прекрасно знаете с чем сопряжены операции сравнения.. условного перехода и т.д. и т.п.. Я не говорю что ТАК сделано у всех.. но у большинства из тех кого я видел. Хотя заметьте.. Ни разу в практике налогов ЛР не было смены налога в середине месяца (видимо все же правительство и себе не хочет лишней головной боли)... Вывод? В году не так уж и много месяцев чтобы делать это в виде диапазонов.. можно завести справочник для каждого отдельного месяца. Операция выборки осуществляется гораздо быстрее! И никаких сравнений и условных переходов (это все к вопросу оптимизации и снижению ошибок). Подобные решения я видел.... но почему-то не у всех.. хотя это и самое простое решение. За десять лет это всего лишь 120 строк в таблице... за 100 лет... 1200.. и всего-то!

.. с одной оговоркой... для одного налога.

Наверное зря я начал об этом.. сейчас ОПЯТЬ начнутся упреки... посылки к теории БД... к моей неопытности... а если я такой умный почему сам это не делаю..