Платформа Аллегро ... баннер перед носом ... чуть выше..

← →
kaif © (2004-04-16 15:50) [200]

2 serge35

А "иерархические справочники"? Которые так легко мне реализовать, но которые я запретил как понятие в Allegro и заменил их системой классов на основе реляционной модели?
Думаете мне не проще было сделать такую вот табличку:
ID PARENT_ID NAME ATTRIBUTES
=============================
1 1 "вася" 13

И еще к ней одну, примерно такую:
ATTR_ID ATTR_NAME VALUE
=============================
13 "номер паспорта" 1231231

А почему я так не сделал?
Потому что я знаю, чем все это заканчивается потом.
=============================
Так что Вы несправедливы. Не поленитесь.
Посмотрите сначала систему.
Я знаю, что именно из предубежденных людей потом получаются самые верные соратники.
:)

← →
kaif © (2004-04-16 15:56) [201]

Извините, я на сегодня покину форум. Нужно ехать в одно место.

← →
kaif © (2004-04-16 15:59) [202]

Повторюсь, скачивать систему не обязательно. На сайте есть описания в формате PDF для скачивания и точно такие описания выложены в HTML-формате прямо на сайте в разделе "Документация":
http://www.gaapinvest.com/allegro/doc/index.html
"Руководство пользователя" пока не полное. Извините.

← →
serge35 (2004-04-16 16:03) [203]

Я тоже покидаю форум на пару недель - надо лететь к заказчику и продолжать разгребать отчетность.

Можно и без использования иерархических справочников нагородить.
А отказываться от их использования неразумно.

← →
euru © (2004-04-16 16:08) [204]

>kaif © (16.04.04 15:44) [199]
В SAP R/3 система в общем случае разделена на 3 уровня:
1. пользовательский (бухгалтеры, кладовщики и т.д.)
2. экспертный (специалисты по функционалу системы)
3. базисный (администраторы, программисты).

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

← →
DiamondShark © (2004-04-16 16:26) [205]

> Таким образом, снимается проблема некомпетентности пользователей
> в вопросе настроек системы

И вводится проблема некомпетентности настройщиков в предметной области ;-)

← →
serge35 (2004-04-16 16:35) [206]

Я предлагал авторам более глубоко изучить предметную область для которой пишется система.

← →
euru © (2004-04-16 16:35) [207]

>DiamondShark © (16.04.04 16:26) [205]
Вообще-то они за это деньги получают. В их прямые обязанности входит знание предметной области и функционала системы.

← →
Сергей Суровцев. (2004-04-16 23:32) [208]

>kaif © (16.04.04 01:45) [150]
>Спасибо за взвешенное и объективное мнение. Согласен почти
>со всем, кроме того, что между GAAP и нашим
>регламентированным учетом можно поставить знак равенства.

А я и не ставлю знака равенства. Ибо это совершенно несравнимые
понятия. GAAP - это сборник принципов ведения бухучета.
На основе него должен строится не план счетов как таковой,
а система законадательства, придерживающаяся этих принципов.
А план счетов - это лишь производная от этого законодательства.
Этакий шаблон, стандартная заготовка для отражения правильности
выполнения законодательства, реализующего принципы GAAP. :))
Поэтому проблема не в плане счетов, как таковом, а в собственно
определении функции бух.учета на предприятии. В советской
системе основная задача бух.учета определялась как "не давать
уворовать". С дебильным учетом всего и вся. Сейчас бухгалтерия
потихоньку осваивает азы финансового анализа, сути и принципов
движения и работы капитала, а не просто его учету. И логику
здесь ломать нужно в корне, это верно.
Но сама идея регламенторованного плана счетов мне нравится
больше чем свободный поиск, ибо позволяет быстрее вникнуть в
сторонний процесс.
А насчет "денег в пути"... "Товаров в пути" никогда не видел,
видимо уже не застал и не в курсе что это, а "деньги в пути"
это чисто техническая проблема, скажем инкасации, когда Ваши
деньги из кассы становятся Вашими же деньгами в банке, но
не мгновенно, а лишь на следущий день. А проводка может
содержать только одну дату. Кроме того эти деньги на время
выпадают из Вашего оборота, в этот момент они, конечно, Ваши,
но распорядиться ими Вы не можете. Так что все вполне логично.

Лучше скажите мне другое. Почему Вам лично и GAAP в целом так
не нравятся развернутые счета? Это же идеальный механизм
реального учета задолженности. Причем в реальном времени.
И после любой проводки можно сразу сказать кто кому сколько
должен. В чем плюс от работы без них, при очевидных минусах?
Мне это непонятно. Я знаю о способе скрывать реальную картину
долгов сворачивая эти счета, но ведь это же можно и запретить.
Зачем же ломать красивую схему?

>Danilka © (16.04.04 08:34) [152]
>Для справки: на ВАЗе в плане счетов несколько сот тысяч
>счетов (по крайней мере год назад так было). :)

Уж не контрагентов ли они по счетам расписывают? Руки за
такой план счетов отрывать нужно.

>Danilka © (16.04.04 14:01) [181]
>Судя по статье, ссылку на которую дал Думкин, в аксапте и
>других буржуйских системах перепроведения нет, а пользуюцца
>ими во всем мире..

Любой уважающий себя программист такую связку сделает. Даже
если в системе и не будет перепроведения. Хотя бы возможность
повторно создать проводки быть должна, а для этого нужно
удалять старые автоматом. Кроме того есть немало некритичных
к дате документов, по исправлению которых глупо вносить
коррекцию отдельно, а умно просто провести исправленный
документ заново.

>serge35 (16.04.04 14:33) [183]
>Я занимаюсь устранением последствий работы "гениальных" идей
>в области финансов.

Одни завоевывают кубки, другие гравируют на них надписи. (с)

>Polevi © (16.04.04 15:03) [186]
>а у нас - варка бытовой химии

Так, блин, теперь главное не перепутать, не перепутать...

>kaif © (16.04.04 15:50) [200]
>А "иерархические справочники"? Которые так легко мне
>реализовать, но которые я запретил как понятие в Allegro
>и заменил их системой классов на основе реляционной модели?

Ваша система поиска, как я понял, сродни поиску по инвентарным
номерам, но не всегда человек знает что ищет. И ищет он
подобное по смыслу, а не по названию, для чего необходим
полный список.
А сайт мне, кстати, понравился. Все элегантно, лаконично,
информативно. Без выпендрежа и с достоинством.

← →
kaif © (2004-04-16 23:57) [209]

SAP R/3 система в общем случае разделена...

Напоминаю еще раз, что речь идет о компактной, скачиваемой по интернет, дружественной дельфисту, системе разработки, стоимостью $800, предназначенной для автоматизации малого бизнеса.
При чем здесь R3, Аксапта и так далее?
Посмотрите пример действующей конфигурации на сайте:
-------------------------------
Постоянно включенные пользователи:
-------------------
Генеральный директор - 1
Финансовый директор - 1
Менеджеры - 4
Ответственный по складам - 1
Секретарь - 1
-----------------------
Где здесь IT-отдел? Где функциональщики? Где администратор баз данных, администратор сети и "служба поддержки"? Где это все? Ничего такого у малой фирмы не бывает. Обслуживаются ее компьютеры обычно фирмами по договору, программы обслуживаются так же - иногда заходит программист что-то подправить или добавить.
И таких фирм большинство.
Кстати, необязательно, чтобы такие фирмы имели маленькие обороты или маленький бизнес. Такая фирма может иметь десятки собственных магазинов и обслуживать десятки региональных заказчиков по всей стране.
Малая фирма - это особый вид организации, где все друг друга знают, многое построено на доверии, на качестве, высокой взаимозаменяемости и чувстве ответственности. Но у них очень и очень своеобразные задачи и весьма специфическая продукция. И любая программа, которая думает дольше, чем несколько секунд - для них скорее помеха в работе, чем помощник.
Многие из них имеют иностранных партнеров или поставщиков и им нужны адекватные способы общения с ними. Никаких "шахматок" там не понимают. Там понимают, если фирма умеет четко вести взаиморасчеты по самым разным схемам и с помощью любых финансовых инструментов и при этом нигде не путается. И успевает заниматься всем этим как правило всего 1 человек - финансовый директор. Вот то, что мы имеем. Этих заказчиков - море. А предложить им практически нечего.

← →
kaif © (2004-04-17 00:20) [210]

2 Сергей Суровцев. (16.04.04 23:32) [208]

В такой постановке (принципы -> план счетов) я с Вами согласен полностью. Дело не в кривом плане счетов, а в кривости на самых высших уровнях, начиная с законодательства.

Почему Вам лично и GAAP в целом так
не нравятся развернутые счета? Это же идеальный механизм
реального учета задолженности.

О чем Вы спрашиваете? Я не очень понял. Об активно-пассивных счетах типа "Расчеты с поставщиками" ? Если да, то могу Вас обрадовать. Если в программе LEADER Classic у меня чистый GAAP-баланс (без аналитических счетов), то в Allegro впервые применена совершенно другая схема. В среду счетов GAAP внедряются так называемые аналитические регистры счетов. Это не один "ативно-пассивный счнет", а целое дерево, привязанное к одному справочнику. Например, Вы создаете аналитический регистр счетов "Контраганты" с "двумя развернутыми сальдо" в балансе. Привязываете его к справочнику "Контрагенты". Затем создаете в нем счета: "Расчеты с поставщиками", "Расчеты с покупателями", "Расчеты со всякими разными". Allegro автоматически вставляет в баланс 2 счета развернутых сальдо. Их следует переименовать в "счета дебиторов" и "счета кредиторов" и поместить в балансе в соответствующие места (слева и справа). Такой регистр (кластер счетов) позволяет свести в одно место все родственные отношения, когда одни и те же контрагенты выступают то, как поставщики, то как покупатели и осмысленно вести начисления - либо допуская встречного зачета по какаим-то объектам - либо нет. В то же время такой регистр позволяет видеть сразу все отношения с данным контрагентом и общий баланс по всем отношениям с ним. Allegro автоматически рассчитывает развернутые сальдо и двухсторониий GAAP баланс фирмы всегда правильный. Поэтому неверно говорить, что я использую GAAP впику МИНФИНУ. Я взял все лучшее изобразительное от GAAP (отсутствие необходимости нумерации, двусторонний баланс, традицию расположения статей от более ликвидных - к менее ликвидным) и соединил с лучшим техническим из российской традиции (аналитические счета с развернутыми сальдо). Причем российский прием учета был развит до кластера, регулирующего близкие по GAAP-смыслу экономические отношения с объектом. Например, с одной стороны удобно, когда поставщики и покупатели учитываются на разных счетах. Но в то же время с точки зрения финансов никаких поставщиков и покупателей не бывает. Бывают только дебиторы и кредиторы. Как устранить это противоречие? Как позволить с одной стороны создать счет "расчеты с блондинами и брюнетами", а с другой - выполнить всю строгость GAAP-традиции? Мне кажется, что регистры счетов (этакие кластеры) решают эту проблему полностью. Allegro - это синтез двух систем. Поэтому я и говорю, что allegro совместимо как с GAAP, так и с МИНФИНом.

Спасибо за добрые слова в адрес сайта. Я обязательно передам Ваш отзыв WebMaster-у. Его тоже зовут Сергей. :)

← →
kombat © (2004-04-17 01:08) [211]

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

← →
kaif © (2004-04-17 03:00) [212]

2 kombat © (17.04.04 01:08) [211]
Есть еще и третье решение. Именно оно предлагается в Allegro.
Все "периодические" атрибуты можно хранить в документах. Создается тип документа: "наши реквизиты". В нем поля и дата начала действия этих реквизитов. Каждая строка в этой таблице - новая версия реквизитов. Там, где нужна печать реквизитов, используются данные из этой таблицы. Все очень просто и прозрачно. Не обязательно такие вещи держать в справочнике. Причем в данном случае документ будет отражать события, имевшие место. А именно это и есть функция документов - отражать события. И переход из одной налоговой в другую - не какой-то там "исторический атрибут", а именно событие. Кроме смены налогового номера, это событие может содержать и другие важные сведения. А если его разбросать в виде "исторических атрибутов" по разным справочникам, то целостность такого события теряется и всякая прозрачность и надежность данных падает. Новому программисту, который придет развивать систему может быть вообще невдомек, что были такие события, как переход из одной налоговой в другую. Если же он увидит такой тип документа и пару экземпляров в нем, то он сразу поймет, о чем именно шла речь.
Дело в том, что конфигурация Allegro общается с базой данных напрямую через SQL-запросы. И для SQL по барабану, какую таблицу использовать. Для него нет "справочных таблиц" отдельно от "таблиц документов". Но SQL не очень дружит с такими подходами, как "исторические атрибуты". Когда надо на каждом шагу еще и какие-то даты проверять чуть ли не в каждом JOIN.

← →
kombat © (2004-04-17 12:18) [213]

Документы это хорошо и если мы в документе налоговая накладная указываем ссылку на конкретную запись документа "наши реквизиты" (вручную?), то это еще нормально. Но как быть с ситуацией когда есть справочник "Контрагенты", в котором есть контрагент с кодом 100 и у которого 01.01.01 поменялся номер свидетельства. При этом контрагент остался тем же, и везьде он фигурирует по коду 100, т.е. одна запись до и после 01.01.01
Как сделать чтобы все документы выписываемые до 01.01.01 брали одно значение реквизита, а все что после 01.01.01 - другое, новое? Это очень распостраненная ситуация в бухгалтерских и расчетных системах.

← →
Думкин © (2004-04-17 13:06) [214]

> [208] Сергей Суровцев. (16.04.04 23:32)
> >Danilka © (16.04.04 14:01) [181]
> >Судя по статье, ссылку на которую дал Думкин, в аксапте и
> >других буржуйских системах перепроведения нет, а пользуюцца
> >ими во всем мире..
>
> Любой уважающий себя программист такую связку сделает. Даже
> если в системе и не будет перепроведения. Хотя бы возможность
> повторно создать проводки быть должна, а для этого нужно
> удалять старые автоматом.

Вывод один: или буржуинские программисты себя не уважают либо ... расшифруй.

Я вот одного не понимаю, делать все через нелитературное место - это что местная гордость какая-то? Равно как и с лицензионностью программ.

← →
Petr V. Abramov © (2004-04-17 15:03) [215]

> kaif
Сразу оговорюсь, что сам систему (пока) не ставил, не по нежеланию, а по нехватке времени. Так что говорю на основании Ваших постов в ветке и осмотру Вашего сайта.

IMHO, система - 1С.Вид_сбоку. Но этот вид сбоку мне нравится в основним нравится больше, чем чем её (1С) оригинальный вид в ж... :)
> Но SQL не очень дружит с такими подходами, как "исторические атрибуты".
Так это проблема SQL, а не пользователя или разработчика конфигурации. Они нужны.
Отсутствие иерархических справочников - тоже позор, даже не перед 1С, а практически перед любой системой.

Как организовано разделение доступа?
Есть ли визуальное наследование форм?
Поддерживаются ли фреймы?

К тому же учтите, что все же система чаще будет сосуществовать с 1С, чем ее заменять. Потому, что параллельный учет ведется не только для ухода от налогов, но и потому, что методика исчисления прибыли "по Минфину" не всех устраивает. Самый красивый пример - "Сибнефть": "по Минфину" - несколько сот миллионов руб убытка, по GAAP - несколько сот млн. д. прибыли :) И все "в белую" :)

← →
kaif © (2004-04-17 15:32) [216]

2 kombat © (17.04.04 12:18) [213]
Если у контрагентов что-то меняется, то здесь возможны две политики:
Политика 1. Это не важно для истории нашей компании, так как это их история и наша компания не обязана печатать старые документы, имеющие отношение к другим компаниям. Если не дай бог, такое оказалось необходимым (исключительный случай - народ умоляет), то система печати должна позволять отредактировать любой результирующий документ вручную и "оказать людям такую любезность".

Политика 2. Это очень важно для истории. Тогда документы должны содержать соответствующие поля, в которые эти реквизиты копируются из справочника и хранятся в документе. Тогда в справочнике существуют лишь текущие реквизиты, а в документах - исторически истинные.

Таким образом, никакой проблемы здесь вообще не существует. Просто нужно при проектировании конфигурации правильно поставить задачу и отдавать себе отчет в том, что требуется сохранять, а что - нет, что копировать в документы и хранить там, что держать в виде ссылок на "регламентные документы", а что - в виде простых ссылок на справочники. И это жесткие ограничения, которые заставляют разработчика задуматься, а не проектировать конфигурацию как попало. Не надо бояться делать копии каких-то атрибутов. InterBase хранит строки без концевых пробелов. Поэтому можно не жаться. В отличие от dBase, кстати.

Что же касается 1С с ее "историческими атрибутами"... Как впрочем и с возможностью всегда "восстановить удаленные записи" и еще много чем... Я программировал на FoxPro много лет, прежде чем перейти на Delphi и SQL. У меня имеются основания предполагать, что ряд особенностей 1С, выдаваемых за "идеологию учетных систем" связан всего лишь с особенностями реализации dBase - образного неэкономного способа хранения данных и дальнейшего доступа к ним - не в совсем реляционном стиле.

2 Думкин © (17.04.04 13:06) [214
Я согласен с Сергеем Суровцевым насчет того, что система должна позволять в максимальной степени редактировать данные. Буржуи не то, чтобы себя не уважают. Часто законодательство не позволяет им делать то, что хотелось бы сделать программистам. Их законодательство тоже несовершенно и консервативно в каких-то случаях, а устаревшие требования к лицензированию бухгалтерских программ там очень жесткие (и возможно составленные в пользу не лучших ихних софтверных производителей).
Я прочитал статью в пользу подхода "не перепроводить". Там есть ряд правильных взглядов на учет, но и ряд логических натяжек. Одно дело, когда не следует перепроводить (решение принимает конфигурирующий или начальник), а другое, когда невозможно перепроводить (система не умеет). Согласитесь, что если OC не будет уметь удалять файлы с диска, а лишь уметь перемещать их в корзину - мотивировать это тем, что "неправильно вообще удалять документы" было бы большой натяжкой. Всякий разработчик скорее начнет подозревать, что создатели этой ОС просто не нашли, как написать "дефрагментацию" и поэтому разводят философию о "правильных и неправильных подходах".

← →
Думкин © (2004-04-17 16:07) [217]

> [216] kaif © (17.04.04 15:32)

Я согласен, но я не являюсь автором статьи - и всего лишь привел ее в дискуссии. Я какк и сказал, новичек в этом деле и мне весьма забавно и интересно тут, видимо как и вам когда вы перешли от 3Д к сегодняшнему. Со мной примерно такая же метаморфоза приключается.
И я вижу множество логических натяжек и неувязок, и кстати с пресловуто-упомянутой Аксаптой. Я сейчас учавствую в проекте с ней - потею, по мере возможности.
Сама ваша идея мне нравится, ибо абсолютно созвучна моей в другой области - я пришел к такому же подходу, дешевле и проще сделать на основе чего-то типа "Аллегро", чем заново создавать двухколесный на уровне Дельфи. Это моя вам поддержка.
Но в затронутой вами области - только касаюсь, посему вам адекватно выразить не могу. Что и видно по отсутствию моих постов кроме единичных вставок. Но тот что вы говорите о насущном - это вижу, и это так. И кстати если бы я в ряде решений применил ваше - было бы здорово. Но сейчас пока увы.
И меня перепроводкка интересует - не как программная фича, а как именно нормальный подход, в русле той же Аксапрты. Вот зачем он нужен?
Да системам позволяет, но моя мне позволит и проценты с округлений на свой счет переводить - а вот как все таки без совковости?

← →
kaif © (2004-04-17 16:08) [218]

Petr V. Abramov © (17.04.04 15:03) [215]

Спасибо за проявленный интерес!

> Но SQL не очень дружит с такими подходами, как "исторические атрибуты".
Так это проблема SQL, а не пользователя или разработчика конфигурации. Они нужны.

Так как разработчик конфигурации работает при помощи SQL, то он будет против исторических атрибутов. Пользователю все равно, как хранятся данные. Важно, чтобы они были правильными. А как это организовано, в справочниках, в документах, или еще где - пользователю по барабану. Поэтому "исторические атрибуты" не нужны. Во всяком случае, я пока не вижу их необходимости. И даже если увижу, то это будет совершенно иначе организовано, так как проблема здесь в чем-то другом, как я подозреваю.

Отсутствие иерархических справочников - тоже позор, даже не перед 1С, а практически перед любой системой.

Иерархические справочники в ядре убьют строгий учет. Мне все равно, позор это или нет. Мне важно избавить конфигурирующего от кошмара. А пользователя - от ошибок в отчетах и заоблачной совокупной стоимости владения. С таким же успехом я могу сказать, что иерархические справочники - позор существующих систем. Это способ переложить свои проблемы на плечи юзера. В Allegro вместо этого имеется система классов. Я уже устал повторять... Если кто-то хочет - пусть сам добавляет в систему иерархические справочники. У конфигурирующего для этого достаточно средств. Но за последствия потом пусть сам отвечает. Наконец, иерархические справочники - слишком банальная и легко программируемая вещь, чтобы еще требовать ее реализации на уровне оболочки в системе с прямым доступом к базе и такими возможностями проектирования интерфейсов. Я просто исхожу из минимализма. Если будут многочисленные просьбы, то я - добавлю. Пока таких просьб от конфигурирующих не поступало. Только от критиков.

Как организовано разделение доступа?

Есть "косметическое разделение доступа", которое очень легко администрировать. К сожалению, в документации оно пока не описано. Реализовано это так: каждый юзер (interbase) может иметь только одну роль или не иметь ни одной (это та роль, что в CREATE ROLE). Это позволяет организовать дерево, например:
PUBLIC
MANAGER
Vasya
Petya
Katya
ACCOUNTANT
Sveta
STOCKKEEPER
Natalya
Secretar
Имеется интерфейс, в котором слева такое дерево, можно добавлять роли и "перемещать" юзера из одной роли в другую. Выбрав в этом интерфейсе слева пункт - справа назначаются косметические права с помощью птичек:
-к пунктам меню (будут видимы)
-к папкам "проводника по документам" (будут видимы)
-к пунктам попап-меню "создать документ" (будут видимы)

Косметические права лекго конфигурируются, но не защищают от хакерства, так как доступ ко всем объектам в Allegro для простоты по умолчанию создается для PUBLIC. Если стоит задача закрыть доступ к объектам базы данных на сервере, то ее решает конфигурирующий, с помощью команд REVOKE и GRANT в той же среде ролей (ROLE) и юзеров.

Есть ли визуальное наследование форм?

Нет.

Поддерживаются ли фреймы?

Нет.

К тому же учтите, что все же система чаще будет сосуществовать с 1С, чем ее заменять. Потому, что параллельный учет ведется не только для ухода от налогов, но и потому, что методика исчисления прибыли "по Минфину" не всех устраивает. Самый красивый пример - "Сибнефть": "по Минфину" - несколько сот миллионов руб убытка, по GAAP - несколько сот млн. д. прибыли :) И все "в белую" :)

Совершенно с Вами согласен. Allegro не противопоставляется системе 1С. И я знаю, что проблемы не только в разнице белый-черный. Иначе мы бы вообще всем этим не занимались.

← →
kombat © (2004-04-17 16:12) [219]

а одновременный учет в одной БД деятельности нескольких фирм, это тоже излишество или его возможно реализовать?

← →
Думкин © (2004-04-17 16:17) [220]

> [219] kombat © (17.04.04 16:12)

у нас это на уровне - несколько компаний. Это интересует?

← →
kaif © (2004-04-17 16:25) [221]

2 kombat © (17.04.04 16:12) [219]
а одновременный учет в одной БД деятельности нескольких фирм, это тоже излишество или его возможно реализовать?
Если это совершенно идентичные во всех отношениях фирмы (с одинаковой структурой счетов баланса), то можно организовать при помощи слоев. Обычно слои используются для цели многовалютного учета. Но можно использовать и для этой цели. Я много размышляю на ту тему, что Вы затронули. Возможно в будущем Allegro позволит обслуживать параллельно разные балансы разных компаний. Но пока что я боюсь запутать пользователей. Учтите, что чем система сложнее, тем труднее ей начать свой путь на рынке программ. Поэтому пока что я занят созданием более или менее автоматизированного обмена документами между разными базами, нежели объединением учета разных фирм в пределах одной базы.

← →
Massimo (2004-04-17 16:33) [222]

Allegro в основном нравится, но смущает следующая ошибка.
Когда расписываешь позиции шаблона проводки, если в поле "Счет" указывается счет, имеющий номер ("№"), то при нажатиии "OK" выдается ошибка :
"qr_Template_Def: поле "NO_BALANCE" не найдено."
Если номер счета стереть, то ошибка пропадает.

P.S. Привет, Ашот.

← →
kombat © (2004-04-17 16:40) [223]

2 Думкин © (17.04.04 16:17) [220]
да, несколько компаний юридически не связанных, но реально "дружественных". Причем учет в этой группе обеспечивает одна и та же команда бухгалтеров. И в таком случае очень желательно иметь один общий набор справочних данных который ликвидирут дубляж (если несколько баз) и лишний ввод/работу.
2 kaif © (17.04.04 16:25) [221]
Я умом понимаю что "периодические" реквизиты плохо сказываются на производительности. Я не являюсь ярым приверженцем 1С, хотя занимаюсь и поддержкой конфигураций и написанием собственных прог на Delphi/FireBird. Просто "периодические" реквизиты это удобство в использовании. Как ни крути но удобнее запросить НаименованиеФирмы(Дата) - а я дро системы пусть разбирается как это сделать.
Их не обязательно использовать где ни попадя, но возможность очень желательна. Это как отсутствие возможности удаления файла )))
Разработка систем типа Аллегро очень правильный путь хотя бы с экономической точки зрения. Ведь гораздо дешевле написать ядро и потратить на это 1 делфи + пачку компонент и потом дать это ядро в работу группе программеров, чем дать каждому из них 1 делфи + пачку компонент.

← →
kaif © (2004-04-17 16:43) [224]

2 Massimo (17.04.04 16:33) [222]
Спасибо со сообщение об ошибке!
Я ее сейчас воспроизвел. Исправлю.
------------------------
Allegro не идеальная система. Это скорее пока набросок. Но уже серьезный и работающий. Ее можно юзать. Я буду подготавливать все обновления так, чтобы не нарушать совместимость. Технология апдейтов отработана.

← →
kaif © (2004-04-17 16:54) [225]

2 kombat © (17.04.04 16:40) [223]
Я готов обсуждать проблему "исторических атрибутов". Но давайте ее попытаемся философски сформулировать. О чем идет речь? О том, чтобы можно было получать информацию в форме GetAttr(AttrName, Date) или о том, чтобы старые версии "не были видны в справочниках" и система становилась малопрозрачной? А что если это не налоговый номер, а, например, справочная цена товара, курс валюты или ставка налога или еще что-то, что имеет влияние на финансовые результаты?
Можем мы сформулировать такой набор требований к "историческим атрибутам", чтобы не оказать потом "медвежью услугу" тому, кто будет конфигурировать отчеты?
Давайте подумаем на эту тему серьезно. Может быть решение "для удобства" есть. Но оно неочевидное. И нуждается в каком-то жестком ограничеснии. Тогда все встало бы на свои места.
Итак, что мы подразумеваем под термином "исторческий атрибут"? Например, этот атрибут может быть в составе уникального индекса (альтернативного ключа) для описываемой сущности? может ли он иметь тип поля DECIMAL (например, цены вообще решили держать в справочниках, а не в документах, так как "система позволяет")?

← →
Думкин © (2004-04-17 16:55) [226]

> [224] kaif © (17.04.04 16:43)

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

← →
Petr V. Abramov © (2004-04-17 17:13) [227]

> kaif © (17.04.04 16:08) [218]
> Так как разработчик конфигурации работает при помощи SQL, то
> он будет против исторических атрибутов
А начальник - "за". Оно, конечно, некоторого геморроя добавляет, но ни у кого еще руки не отвалились. :)

> Как организовано разделение доступа?
> ... Косметические права ...
> ... REVOKE и GRANT ...
> Есть ли визуальное наследование форм?
> Нет.
> Поддерживаются ли фреймы?
> Нет.
Это (технически) и есть "1С++". Кстати, 1С V8 тоже уже неплохо SQL поддерживает. Сыровата она, конечно (по слухам), но это временно.
А учетная идеология у Вас - хорошая

> Поэтому "исторические атрибуты" не нужны
>> Отсутствие иерархических справочников
> В Allegro вместо этого имеется система классов
А зачем огород городить?
Или, может, я че-то не так понял, и мы о разных вещах говорим?
Классика иерархического справочника с хранением истории - структура предприятия. Ну чем стандартная схема в 2 таблички провинилась?

← →
kaif © (2004-04-17 17:29) [228]

2 Думкин © (17.04.04 16:55) [226]
Я не очень понял последний вопрос.
Мое мнение (подход) в отношении перепроведения я попытаюсь изложить очень подробно.

В программе LEADER Classic у меня были ручные проводки, в которых возможно было:
1. Редактировать их задним числом
2. Использовать остатки или обороты счетов на дату проводки в формулах.
При редактировании проводок задним числом возникал лавинообразный перерасчет всех проводок, которые могли зависеть от данной (тех, в которых использованы остатки или обороты счетов, использованных в редактированной проводке или в проводках, зависящих от проводок, в которых использованы такие данные... в общем, сложная схема взаимозависимостей отслеживалась программой и оптимально "перетряхивалась").
Так вот я заметил одну вещь. Существует такая неприятная вещь, как случившееся деление на 0 в формулах. Некоторые редактирования приводили к таком результату где-то в далеком будущем. Совсем непрозрачному, кстати. Тогда я впервые задумался над тем, а вообще правильно ли это все. Потом я изучал 1Сv7.7 и нашел там подход "черного ящика" в событии
ПриПроведенииДокумента()
и "континуум документов", напоминающий мой континуум ручных проводок в LEADER classic. Эта идеология страдала вот чем. Так как 1С вообще не знает (в отличие от LEADER classic), что там конфигурирующий прописал в ПриПроведенииДокумента(), она вынуждена перепроводить ВСЕ ДОКУМЕНТЫ, следующие в континууме за редактируемым документом. Моя проблема деления на 0 оказалась детской проблемой по сравнению с тем тормозом, который порождает 1С при слетании "точки актуальности" назад. Бухгалтера панически боятся в 1С редактировать документы задним числом вообще. Я видел ситуацию, когда такое редактирование приводило к нескольким суткам в перерасчетах на вшивых 3 тысячах документах (достаточно профессионально написанная конфигурация склада 1С Аспект).
Размышляя на эти тяжкие темы, я пришел к выводу:
1. Редактирование нужно
2. Перепроведение нужно
3. Нужно исключить зависимость результата работы функции перепроведения документа от финансовых результатов (оборотов и остатков на каких-то счетах) на дату проводки.

То есть нужно развязать все проводки друг от друга так, чтобы они аддитивно складывались. Не помню, как математически это правильно назвать. Я называл это "линейностью". То есть одни проводки не зависят от других. Перепроведение задним числом должно сводиться к простому удалению старой проводки и замене ее на новую. И все. И никаких "каскадных перерасчетов".
Однако как это реализовать, если, тем не менее, существуют зависимости между событиями финансовой деятельности? Допустим, мы списали себестоимость проданного товара какой-то проводкой. А потом исправляем (еще более задним) числом документ приобретения, который должен влиять на это списание????
Тогда я решил использовать двухтактную схему. Цифры о том, сколько нужно списать, хранятся в документах, которые "просто линейно проводятся". Но эти цифры можно изменить в самих документах и конфигурирующий всегда может написать процедуру, которая это сделает с максимально возможной скоростью.
Итак, цепочка событий такая:
1. Редактируется (вставляется) документ приобретения.
2. Конфигурирующий смещает "активную дату" всех документов списания.
3. Конфигурирующий вызывает процедуру "расчета" всех документов списания, следующих за этой датой либо тут же, либо потом это сделает юзер в окне "состояние расчетов".
4. Все документы, подвергшиеся такой процедуре, линейно перепроводятся с помощью шаблона одним махом. Дело в том, что хранимая процедура шаблона имеет параметры, позволяющие получить кусок журнала операций сразу для всех документов с такой даты по такую. Поэтому можно удалить все проводки такого типа после какой-то даты и вставить новые одним SQL-запросом.

В результате испытания такой "двухтактной" схемы, я получил суммарное время перепроведения всего, что нужно после вставки "приходного" документа задним числом, в базе данных с 3000 документами менее 1 сек.

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

2 kaif © (17.04.04 16:54) [225]
мое мнение касательно "периодических/исторических реквизитов" таково - они нужны именно для удобства получения какой-то информации на дату, будь то название котрагента, цена товара или курс доллара. Но уже в документах способ их использования делится на две части: все данные что не влияют на расчеты (финансовые результаты) получаются в документе по ссылке, а те реквизиты которые влияют на расчеты получают из справочника и копируются в документ, т.е. отвязывают от справочника.
Конечно все это на усмотрение разработчика конфы, он может сделать и не правильно. Но может не стоит уж очень понижать его уровень влияния на то что и как нужно делать. Ведь та же 1С не отвечает за действия криворуких внедренцев, она лишь дает инструменты.

нужен механизм работы именно с реквизитами которые не копируются а получаются по ID элемента справочника

Petr V. Abramov © (17.04.04 17:13) [227]
> kaif © (17.04.04 16:08) [218]
> Так как разработчик конфигурации работает при помощи SQL, то
> он будет против исторических атрибутов
А начальник - "за". Оно, конечно, некоторого геморроя добавляет, но ни у кого еще руки не отвалились. :)

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

> Как организовано разделение доступа?
> ... Косметические права ...
> ... REVOKE и GRANT ...
> Есть ли визуальное наследование форм?
> Нет.
> Поддерживаются ли фреймы?
> Нет.
Это (технически) и есть "1С++". Кстати, 1С V8 тоже уже неплохо SQL поддерживает. Сыровата она, конечно (по слухам), но это временно.

Формально - да. Но ведь 1С - не самая плохая система? Можно сказать даже лучшая из всех на сегодня. Так в чем же дело? А техническая разница есть:
1. Библиотека VCL, которую предоставляет Allegro содержит сотни компонентов, в отличие от куцого набора 1С
2. Allegro поддерживает несколько нормальных и знакомых программистам-профессионалам скриптовых языков, а 1С - русифицированное FoxPro с кучей своих экзотических изобретений.

А учетная идеология у Вас - хорошая

Спасибо! Честно говоря именно это и есть моя цель. Allegro - всего лишь одна из возможных реализаций, к тому же ограниченная моими способностями и познаниями в области программирования, которые весьма скромны.

> Поэтому "исторические атрибуты" не нужны
>> Отсутствие иерархических справочников
> В Allegro вместо этого имеется система классов
А зачем огород городить?
Или, может, я че-то не так понял, и мы о разных вещах говорим?

Возможно мы говорим о разных вещах. В allegro реализована система классов справочников с наследованием атрибутов старших классов младшими классами на основе строгих реляционных таблиц. Это позволяет делать при помощи SQL любые быстрые выборки с группировками. Комбинаторно полные и качественные. Деревья (особенно в справочниках товаров) ведут к мусору и непрозрачности, к урезанию атрибутики конкретных сущностей или подмене и искажению этой атрибутики. Потом отчеты не собрать. И объекты не так легко искать, как многие думают. Защиты от дубликатов по предметным атрибутам - никакой вообще. В общем, проблем много. Поверьте, что иерахический справочник - первое, что приходит в голову, но не самое правильное решение.

Классика иерархического справочника с хранением истории - структура предприятия. Ну чем стандартная схема в 2 таблички провинилась?

Это конфигурирующий может организовать вручную.

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

Я не против деревьев как таковых. Вон баланс у меня - сплошные деревья. В деревьях "Проводника по документам" лежат документы так, как юзер пожелает. Я же не говорю, что баланс МИНФИНА неправильный от того, что там нет деревьев.

Деревья, регулируемые юзером, хороши, когда мы делим однородное пространство. Например, пространство имен файлов на диске(список видный глазу). Или пространство счетов баланса (финансы). Или раскладываем документы "чтобы много в одной папке не скапливалось". Но когда мы создаем справочную систему для товаров, имеющих "вид", "цвет", "марку", "артикул", "дизайн" или "число писксел на дюйм", "производителя", "дюймовость по диагонали", "обороты винчестера" и так далее и хотим потом иметь анализ продаж и другие исследования, в этих случаях, папочки - смерть для учетной системы.
И все базы данных (прайс-листы) по товарам имеют иную идеологию, чем дерево. Это как правило множетсво таблиц с различным набором полей. А вот как все это связать в "Товар"? Чтобы это все быстро работало? Эта проблема и решена в Allegro. Решена через то, что один объект (товар) может одновременно быть строкой в 3 или в 5 таблицах разных классов. Он "разбирается" и "собирается". Вероятно я плохо изложил этот момент в документации. Если столько вопросов на эту тему.

> kaif © (17.04.04 17:29) [228]
Идея очень здравая. Но
> и конфигурирующий всегда может написать процедуру, которая это
> сделает с максимально возможной скоростью.
А может и не написать. Что тогда? Можно перепровести, хотя бы за 3 дня?

2 kombat © (17.04.04 17:30) [229]
Я подумаю на этот счет. Мне нужно несколько дней. Я изложу свою точку зрения. Возможно Вы и правы. Я сейчас не помню то соображение, которое меня отвергло от такой реализации.

Petr V. Abramov © (17.04.04 17:59) [232]
> kaif © (17.04.04 17:29) [228]
Идея очень здравая. Но
> и конфигурирующий всегда может написать процедуру, которая это
> сделает с максимально возможной скоростью.
А может и не написать. Что тогда? Можно перепровести, хотя бы за 3 дня?

Я не понял вопроса. Конфигурирующий обязан такое написать. Если он не напишет процедуру ПриПроведении() в 1С тоже ничего проводиться не будет вообще.

Или Вы полагаете, что 1С что-то сама делает?

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

2 kombat © (17.04.04 17:46) [230]
Такой вопрос. В 1С я не помню, как сделано.
Откуда берется дата для "исторического атрибута"? Например, директор поручил менеджеру отредактировать налоговый номер. То сделал это с опозданием на неделю.
Какая дата (ввода данных или дата изменения налогового номера?) должна стать частью автоматичсеки формируемого "исторического атрибута"?
Или нужна настройка таких атрибутов типа птички "обязательно запрашивать дату, считающуюся датой начала действия нового значения атрибута"?
Нужен ли тогда запрет на редактирование истории?
Что делать с документами, которые уже использовали неправильное значение атрибута (которое нужно редактировать)?
Не будет ли юзер интерпретировать исторический атрибут, защищенный копированием в документ, следующим образом: я изменил значение исторического курса валюты, почему у меня документы не пересчитались? И звать программиста, чтобы тат "исправил" положение?
Пока столько вопросов.

> kaif © (17.04.04 17:58) [231]
> Но ведь 1С - не самая плохая система?
Вроде в Ваш адрес слово "ацтой" не фигурировало :)
> Можно сказать даже лучшая из всех на сегодня.
Не можно :) Просто самая раскрученная.

> что один объект (товар) может одновременно быть строкой в 3
> или в 5 таблицах разных классов. Он "разбирается"
> и "собирается".
Если Вы против того, чтобы в одной таблице сосуществовали и товары ("Г... куриное") и их группировки ("Удобрения органические"), но не против того, чтобы группировки были иерархическими - тогда я поддерживаю. Иначе - не понял :)

Еще вот что.
Некоторые воспринимают изложенные подходы так, будто я не уважаю программиста и считаю его кретином. Это вовсе не так, скорее наоборот - я многих возможностей лишил юзера, рассчитывая на высокое искусство программиста. Я исключаю те возможности, которые приводят фатально к конфликту программиста с юзером. Юзер считает, что "если так можно, то почему бы не". А программист (опытный) - против и теряет заказчика. Неопытный сохраняет заказчика, идя у него на поводу, но становится, как правило, жертвой юзера.
Юзеры обычно не жалуюся на "отсустствие" каких-то возможностей. Они купили этот продукт и он их, следовательно, устроил по цене и возможностям. Они как правило высказываются о недостатках программы в виде пожелений, а не требований. Но если они получают какие-то дополнительные возможности, например, городить папки в справочнике товаров, а потом получают отказ на пожелание "собрать отчет", то они очень обижаются, так как их многодневная и честная работа по "классификации" товаров оказывается выброшенной в мусорный ящик.
Например, они создали такоую иерархию (без дураков!):

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

А теперь покажите, как такое возможно в Allegro, если там нет иерархических справочников вообще.

2 kaif © (17.04.04 18:26) [236]
Как это сделано в 1С
Периодический реквизит это таблица вида
ДатаНачалаДействияРеквизита ЗначениеРеквизита
именно начала действия а не дата ввода юзером

История может редактироваться вручную, так же её могут писать документы. Если значение на дату уже есть, то он изменяется на новое

>> Что делать с документами, которые уже использовали неправильное значение атрибута (которое нужно редактировать)?

А ничего не делать, все периодические значения (которые работают по ссылке на ID) могут быть использованы только для печатных форм (для отображения), т.е. документ просто распечатывается заново. А те которые были скопированы в документ уже вообще к справочнику никакого отношения не имеют.

Вообще периодика нужна только для печати и подстановки значений.

>> Не будет ли юзер интерпретировать исторический атрибут, защищенный копированием в документ, следующим образом: я изменил значение исторического курса валюты, почему у меня документы не пересчитались? И звать программиста, чтобы тат "исправил" положение?
А вот это задача програмиста (или helpа) расказать пользователю что скопированный реквизит уже никак не связан со справочником и не обязан пересчитывать все.

а насчет иерархии в справочнике, то она нужна как минимум для таких случаев как справочник Контрагенты. Где есть Папки "Покупатели", "Поставщики" и пр. и элементы - сами фирмы. Именно Папки а не элементы под видом папок. Пользователь не может выбрать Папку как значение в документ или отчет. Они нужны только для визуального разграничения. Это много удобнее разделить тысячу контрагентов по папкам (как документы, Вы же не скидываете в один список Приходные накладные и банковские выписки) чем искать в общей куче. При всем при этом все записи показываются если мы стаем на вершину дерева и можно искать среди всех а не только в папке.

Платформа Аллегро ... баннер перед носом ... чуть выше.. Найти похожие ветки