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

← →
kaif © (2004-04-14 18:21) [80]

Тенденция в сторону GAAP уже становится фактом:
Компании могут быть освобождены от обязанности вести бухгалтерскую и финансовую отчетность по российским стандартам.
http://www.arni.ru/arni/smpage.fwx?page=1435&news=1000

← →
DiamondShark © (2004-04-14 18:25) [81]

> kaif © (14.04.04 18:14) [79]

Я так и предполагал.

А просветите ламера, GAAP -- это что? Стандарт учёта?
Вы его так нахваливаете, что захотелось ознакомиться.

← →
kaif © (2004-04-14 18:40) [82]

General Accepted Accounting Principles. Принятая в США система принципов ведения учета. В США нет регламентированного учета. Там есть принципы (их немного - всего штук 10), по которым попросту все ведут учет. Например, принцип реализации - доход учитывается в момент доставки услуги (товара) клиенту, а не в момент оплаты.
Подробнее о некоторых принципах:
http://www.gaapinvest.com/allegro/doc/book1/doc017.html

И ВОТ ЭТО считается слишком сложным для понимания нашими бухгалтерами.

Разница между GAAP и нашей бухгалтерией в том, что знание GAAP напоминает знание принципа умножения и умение умножать в столбик. А наша бухгалтерия - это целый ряд таблиц умножения, освященных и регламентированных МИНФИНом. Унаследованных с тех добрых времен, когда слово Капитал считалось матерным, и соответствующее понятие нужно было изжить, но при этом бабки тем не менее как-то считать...

← →
kaif © (2004-04-14 18:50) [83]

Буквально следующая страница документации - элементарный пример того, как ведется бухгалтерский учет:
http://www.gaapinvest.com/allegro/doc/book1/doc018.html
Мы включили некоторые сведения по бухгалтерскому учету в стиле GAAP в документацию по Allegro. Мышление "от баланса", а не "от проводок" - есть главное различие американского бухгалтера и нашего.

← →
kaif © (2004-04-14 19:08) [84]

Пример того, как может выглядеть баланс есть на странице:

http://www.gaapinvest.com/allegro/doc/book3/doc003.html

Счета не регламентированы, нумерации не имеют, но их состав не случаен. Он отражает специфику деятельности данной компании с одной стороны и содержит основные общепринятые разделы - с другой стороны. Таким образом, если МИНФИН над головой не стоит, бухгалтер (сегодня за него это уже делает финансовый директор, так как от нашего бухгалтера обычно толку мало) может составить систему счетов, наиболее точно отражающую главные финансовые показатели компании на языке, понятном инвесторам, кредиторам и директору.

← →
Тимохов © (2004-04-14 19:16) [85]

Ашот, вы идеалист :)))
Я тоже примерно тем же, что и вы занимаюсь.
Отличие в том, что мы больше нацелены на нескольких, но крупных клиентов.
Все же не видно желание фининсовых диреторов внедрять gaap. Учитывать они и так умеют.

Может это конечно специфика крупных предпиятий... не знаю...

← →
kaif © (2004-04-14 19:49) [86]

2 Тимохов © (14.04.04 19:16) [85]

Да, я идеалист. Просто я испытываю к российскому счетоводству приблизительно такие же чувства, как многие дельфисты к встроенному языку 1С.
Кстати, что касается крупных компаний. Как ни странно, но их учет более примитивен, несмотря на большие объемы. Как правило все стандартные операции там можно свести всего к нескольким базовым типам. И советская бухгалтерия довольно адекватно отражает их деятельность. Возможно, она и разрабатывалась для в основном крупных предприятий и монстрической плановой экономики. В которой стандартизация дает больше плюсов, чем минусов.
Но у малых фирм деятельность очень сложная. И отношения с внешним миром самые разнообразные. И здесь засунуть это все в прокрустово ложе стандартных счетов означает убить всю отчетность на корню. Поэтому обычно на малых фирмах вся ценная информация находится в каких-нибудь "субконто" и как-то иногда выуживается на божий свет. Сам баланс в формате МИНФИНА для них - просто несколько глупых и ничего не говорящих цифр.
Система Allegro не ограничивает в том, чтобы вести российскую систему счетов. Это так сказать, частный случай. Пожалуйста - заводим счета в соответствии с МИНФИНом (в программе есть необязательное поле - код счета). Зато есть один маленький плюс - при изменении нумерации не произойдет катастрофы, которая не так давно постигла множество конфигураций, считавших принятую нумерацию счетов настолько незыблемой, что даже заложились на использование этих номеров в качестве естественных ключей в базах данных (вместо суррогатных ID, как это делается в Allegro). И эту свинью подложил все тот же МИНФИН. Спрашивается, как после этого можно серьезно относиться ко всем этим номерам? Ведь многие бухгалтера делают проводки, даже не понимая, что стоит за этими номерами. И гордятся тем, что помнят все "корреспонденции" наизусть. Даже книжки такие выпускаются: "50 тыс. примеров хозяйственных операций.". Разумеется, после каждого изменения нумерации или "таблицы умножения" МИНФИНА, нужно купить еще одну такую книжку. Хороший бизнес, надо сказать...
А я когда задаешь самый элементарный вопрос - не могут ответить. Например, я как-то спросил молодого бухгалтера, из каких соображений инвестор вообще вкладывает деньги? Девушка покраснела и сказала: "Они (запад) просто хотят нам помочь...". Прямо в духе Остапа Бендера! :)

← →
Polevi © (2004-04-15 10:25) [87]

>kaif © (14.04.04 19:49) [86]
меня смущает возможность привязки к счету только одного уровня аналитики
у 1С 6 версии было 3 уровня

← →
Digitman © (2004-04-15 10:47) [88]

> kaif © (14.04.04 19:49) [86]

вопрос по уникальности объекта в справочнике ..

к примеру я создал базовый абстрактный класс (TBase) с парой неких атрибутов TBase.Attr1 и TBase.Attr2, далее создал класс-наследник (TDesc = class(TBase)) с еще одним доп.атрибутом TDesc.Attr1

теперь мне требуется обеспечить уникальность будущих объектов класса TDesc по совокупности аттрибутов TBase.Attr1, TBase.Attr2, TDesc.Attr1

каким образом я должен сгенерировать констрейнты/индексы для обеих таблиц, так чтобы обеспечить требование ?

← →
LordOfSilence © (2004-04-15 11:25) [89]

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

← →
Danilka © (2004-04-15 11:29) [90]

[89] LordOfSilence © (15.04.04 11:25)
В смысле, что значит "двойная запись"?

← →
Тимохов © (2004-04-15 11:31) [91]

> В смысле, что значит "двойная запись"?

дебет/кредит

← →
LordOfSilence © (2004-04-15 11:31) [92]

ну, проводки - дебет и кредит.

← →
Danilka © (2004-04-15 11:33) [93]

Как я понимаю, раз ГААП, то значит и составные проводки.

← →
Danilka © (2004-04-15 11:34) [94]

Кстати, в той древней версии что у меня, именно так:
одна проводка - две или больше записей.

← →
Тимохов © (2004-04-15 11:35) [95]

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

Когда пришли к нам (у нас в основе всего лежит принцип двойной записи) в начале сказали - "Двойная запись фигня". Но прошло время и пришло осознание, что двойная запись незаменимая вешь.

Так, что не считаю это недостатком.

← →
Тимохов © (2004-04-15 11:36) [96]

> Danilka © (15.04.04 11:34) [94]

Имохо способ формирования проводок не принципилен. Но в гаап он опять же имхо более информативен.

← →
Danilka © (2004-04-15 11:37) [97]

[95] Тимохов © (15.04.04 11:35)
На самом деле по международным стандартам бухучета есть операции, когда, например, в дебете три счета в а кредите два.
Проводкой с двойной записью такого не сделаешь.

Правда, в российском бухучете (и в немецком, если не ошибаюсь) такого нет.

← →
Тимохов © (2004-04-15 11:39) [98]

> Danilka © (15.04.04 11:37) [97]

Термин "двайная" идет не от количества операций, а от двойки дебет+кредит.

← →
Danilka © (2004-04-15 11:41) [99]

[98] Тимохов © (15.04.04 11:39)
Хм, а какие тогда есть варианты, кроме дебет+кредит?

← →
LordOfSilence © (2004-04-15 11:47) [100]

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

← →
Тимохов © (2004-04-15 11:52) [101]

> LordOfSilence © (15.04.04 11:47) [100]

Через двойную запись можно учеть что угодно (в разумных пределах). Другое дело, что не все потребители готовы это понять.

← →
Danilka © (2004-04-15 11:54) [102]

[100] LordOfSilence © (15.04.04 11:47)
В смысле?
То-есть, там нет возможности, например, сделать какие-нибудь документы без проводок и отчеты по ним?
Честно говоря, сомневаюсь. :)

Думаю, можно и подобие регистров в 1С сделать, например, триггерами на таблицах документов.

[101] Тимохов © (15.04.04 11:52)
Ну, например в 1С есть механизм регистров, довольно удобная вещь (иногда). :))

← →
LordOfSilence © (2004-04-15 12:00) [103]

2 Danilka © (15.04.04 11:54) [102]
Вот и я на подобие регистров намекаю ;-)

← →
serge35 (2004-04-15 12:01) [104]

>экспортировать оттуда документы

Может импортировать оттуда или экспортировать туда?

>Просто я испытываю к российскому счетоводству приблизительно такие же чувства, как многие дельфисты к встроенному языку 1С.

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

Любая надстройка над языком программирования ограничивает возможности этого языка.

Если меня попросят создать базу данных за 500$, то возьмусь за нее, если в ней не более 5 таблиц.
А вообще таких заказчиков надо отправлять в 1С. Их место там.

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

← →
Danilka © (2004-04-15 12:10) [105]

[103] LordOfSilence © (15.04.04 12:00)
Мне кажется, это как-раз серверная часть. Считать регистры надо серверу триггерами, например, чтобы не тянуть все на клиента.
В этом случае, никакого специального механизма в самой системе может и не быть. Правда, могу и ошибаться, давно я Аллегро смотрел.

← →
LordOfSilence © (2004-04-15 12:33) [106]

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

← →
Danilka © (2004-04-15 12:50) [107]

[106] LordOfSilence © (15.04.04 12:33)
Понятно. Просто, я хотел сказать, что какое-то подобие можно сделать и самому, со стороны базы. А в следующих версиях, наверняка много чего добавицца. Регистры в 1С-ке, как я понимаю, тоже не сразу появились. :)

← →
serge35 (2004-04-15 12:52) [108]

Я не удивлюсь, если через пару лет эта система будет в точности соответствовать 1С.

Ух ты, как много вопросов! И главное - все по существу. Постараюсь ответить по порядку.

Polevi © (15.04.04 10:25) [87]
меня смущает возможность привязки к счету только одного уровня аналитики
у 1С 6 версии было 3 уровня

отвечу в связи с

LordOfSilence © (15.04.04 11:25) [89]
А теперь о том, что мне действительно не понравилось.
Это то, что Аллегро на текущей момент оринтирована только на один математический механизм учета, а именно: только двойная запись (поправь, если это не так).

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

serge35 (15.04.04 12:52) [108]
Я не удивлюсь, если через пару лет эта система будет в точности соответствовать 1С.

Посмотрите внимательно, как устроен баланс-навигатор и Вы убедитесь, что это станет возможным лишь когда 1С научиться (от Allegro) реализовывать такие вещи.

Далее
LordOfSilence © (15.04.04 11:25) [89]
1. Как я уже говорил в аське, общие реквизиты документов могут оказаться полезными.

Это для меня болезненный вопрос. Возможно, ты и прав. Однако, если ты посмотришь внимательно "Проводник по документам - ты обнаружишь там такие общие поля. Они не реализованы, как классы справочников (то есть это не одни и те же поля таблицы-предка), они реализованы, как интерпретация полей таблиц разных документов, как "поле даты", "поле номера", "поле суммы" и "поле примечаний". Это более гибкий механизм. Может быть имеет смысл развить его, так как он себя сразу хорошо зарекомендовал. Разумеется для SQL-запросов это плохой подход (требует UNION и плохо дружит с ограничениями на уникальность). Но если подумать в этом направлении дальше, то, возможно мне удастся найти компромисс между тем, что ты хочешь и тем, как это можно организовать в "рыхлой" системе документов. Меня сдерживают некоторые возможности сервера IB. Например, "динамический SQL" возник не так давно и только в Firebird. В Yaffil-е этого пока вроде нет. Когда все сервера (и мои навыки) подтянутся в этом вопросе, возможно будет небольшая "революция" и в Allegro.

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

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

2. Как насчет "исторических" значений справочников? Есть или будут ли они?

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

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

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

Digitman © (15.04.04 10:47) [88]
вопрос по уникальности объекта в справочнике ..
к примеру я создал базовый абстрактный класс (TBase) с парой неких атрибутов TBase.Attr1 и TBase.Attr2, далее создал класс-наследник (TDesc = class(TBase)) с еще одним доп.атрибутом TDesc.Attr1
теперь мне требуется обеспечить уникальность будущих объектов класса TDesc по совокупности аттрибутов TBase.Attr1, TBase.Attr2, TDesc.Attr1
каким образом я должен сгенерировать констрейнты/индексы для обеих таблиц, так чтобы обеспечить требование ?

К сожалению, эта задача так в лоб не решается. Я могу сказать, как похожую задачу я решал у одного заказчика в Allegro. Имелись разные классы товаров, потомки "Товара вообще". Каждый класс имел свой набор уникальных атрибутов в виде ссылок на пару справочников (у каждого класса на свою пару "Дизайн" и "Вид"). Мы сделали следующее: мы создали уникальный код из 3 цифр
VARCHAR(3) для каждого "вида" и "дизайна". Причем так как каждый из этих справочников был потомков "вида вообще" и "дизайна вообще", то эти коды хранились в этих базовых классах и имели уникальные индексы. Далее, я сделал триггеры AFTER INSERT и AFTER UPDATE для всех таблиц конкретных товаров, в которых "склеил" конкатенацией 2 кода (дизайн+вид) в код "артикул", который помещал колонку "Артикул" "Товара вообще" с помощью вызова команды UPDATE "Товар вообще" SET "Артикул" =.
Чтобы обойти требование NOT NULL на колонку "Артикул", которое срабатывет прежде, чем эти триггеры (вставка в базовый клас происходит раньше), я вписал в триггер BEFORE INSERT базового класса товаров временное присвоение значения ID полю "Артикул". После чего уникальный индекс "Артикул" "товара вообще" стал обслуживать все потребности в уникальности.
Решение только на первый взгляд сложное. На самом деле все очень просто и четко работает. Секрет в том, чтобы в триггеры встроить модификацию какого-то поля базового класса, а уже там иметь нужную уникальность.
В твоем случае можно поступить даже наоборот. Создать дополнительное поле в классе TDesc и при помощи триггера помещать туда копию поля из TBase. И назначить составной уникальный индекс по дву полям в таблице класса TDesc. А в интерфейсах сделать это второе поле невидимым (такая возможность есть).

← →
serge35 (2004-04-15 15:37) [110]

Я не думаю, что 1С нуждается в передовых технологиях Аллегро.

> serge35 (15.04.04 15:37) [110]

Вы в 1с не работаете?

моя имхо говорит, что 1с вообще ни в чем не нуждается - они свое дело уже сделали.

← →
serge35 (2004-04-15 15:52) [112]

Не работаю, но за те годы, которые существует 1С просто нельзя не сделать бухгалтерской программы.

По-поводу "рыхлой" системы документов и UNION.
Пардон еще раз, сейчас у меня даже Delphi не установлена, не то что Аллегро, поэтому говорю вслепую. Наверняка у тебя в системе есть таблица, где перечислены все заголовочные строки документов. Почему бы общие поля документов не подпихнуть туда?
По-поводу таблиц настроек.
Имеется ли возможность использовать элементы (строки) таких таблиц в качестве атрибутов справочника? Пример: есть справочник сотрудников. Один из атрибутов - пол сотрудника. Есть резон выделить сущность пол в отдельный нередактируемый справочник (таблицу настроек) с предопределенными значениями "муж", "жен" и для политкорректности "транс", дабы у пользователя не было соблазна городить в этом справочнике ахинею. Затем, элементы уже этого справочника подставляются в атрибут "пол" для конкретного сотрудника.

Что касается двойной записи, аналитики в более, чем 1 поле и так далее, постараюсь разъяснить подробнее.
Принцип двойной записи (в понимании sum(debit) = sum(credit) тесно связан с остальными принципами GAAP, в частности, с принципом балансового уравнения (Средства = Обязательства + Капитал). Поэтому если мы хотим видеть текущее финансовое состояние компании (баланс) и текщую прибыль (в составе этого баланса), мы должны применять принцип двойной записи. Он регулирует отношения собственности. Невозможно, чтобы возник у кого-то долг или куда-то делись деньги просто так, с бухты барахты. Значит, это произошло за счет чего-то другого (средства не берутся с потолка и не исчезают непонятно куда). Поэтому вся часть, связанная со счетами контрагентов, прибылями и учетом средств (баланс) будет всегда опираться на принцип двойной записи и ни на что иное опираться не может.
Одно аналитическое поле является излишество даже в классическом GAAP. Там ничего, кроме счетов вообще нет. Просто аналитическое поле позволяет избавиться от необходимости переставлять счета из левой стороны баланса в правую, и наоборот (когда должник превращается в кредитора и наоборот) автоматизировав этот процесс в целях удобства.
К сожалению, техническая возможность создавать аналитические поля приводит к искушению (как было в 1С) нагрузить финансовый учет несвойственными ему признаками, заодно используя этот вид "сумматора" как сумматор "как таковой" для всевозможных иных целей (множество аналитических полей). Например, для выяснения не только того, где находятся средства, но и кто за них "отвечает", "кто их привез или поставил", "куда их потом со склада нужно будет отправить" и так далее. Все это плохо интерпретируется в рамках модели отношений собственности и приводит к противоречиям, когда мы задаемся вопросом "а что означает остаток на таком-то счете в таком-то разрезе?". В результате часто такие данные страдают неполнотой (не всегда указывалось, кто привез и для кого, так как кое-что привозили для себя или непонятно у кого брали) и так далее. Все это оттого, что финансовый учет не должен был изначально ничего такого содержать вообще. Средства либо лежат на счете склада и принадлежат компании (в виде товара), либо лежат на счете складовщика (он должен деньги, но уже никак не товар), либо на счете поставщика (тот должен деньги, но никак не товар). Они не могут одновременно быть и там и там и там.
Поэтому в конце концов 1С это поняли и ввели регистры для "всяких разных других дел". Однако рудимент нескольких "субконто", так подкупающий юзера, который не знает, что такое баланс, но спешит вводить данные - остался и является большой головной болью при каждом апдейте конфигурации 1С, когда все эти "левые" субконто теряются, а пользователи проклинают все на свете.
Система регистров ресурсов - вещь удобная, но не имеющая прямого отношения к финансовому положению компании. Если компания купила 10 тонн какого-то материала и что-то там из него произвела, потратив на это еще и электроэнергию и нервные клетки, то это ее личное дело. И от того, как именно она склонна считать себестоимость каждой единицы, как она прогнозирует дальнейшее производство и его выгодность/невыгодность, на ее финансовое положение это никак не влияет. Поэтому все это должно быть вне баланса и бухгалтерских проводок. Максиму, что она может отразить в балансе - сам факт того, что материал использован и дальнейшей перепродаже в качестве материала больше не подлежит.

> kaif © (15.04.04 16:02) [114]

С тем фактом, что в многие факты не должны быть в бух проводках я согласен целиком и полностью.

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

Куда вы предлагаете девать всю дополнительную информацию?

[115] Тимохов © (15.04.04 16:07)
Вообще, как вариант, в проводки можно писать ID документа, по которому они были сделаны. В этом случае, вся экзотика легко вытаскивается из док-та.
Правда, я не знаю как это здесь реализовано, вообще, такое возможно если id уникально для всех документов (что, вобщем-то сделать легко, если для генерации id любого док-та дергать один генератор на всех)

LordOfSilence © (15.04.04 15:58) [113]
По-поводу "рыхлой" системы документов и UNION.
Пардон еще раз, сейчас у меня даже Delphi не установлена, не то что Аллегро, поэтому говорю вслепую. Наверняка у тебя в системе есть таблица, где перечислены все заголовочные строки документов. Почему бы общие поля документов не подпихнуть туда?

У меня в ядре нет такой таблицы. Хотя сама идея мне нравится.

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

Нет, из таблицы настроек поле не может попасть в справочник. Если речь идет не о "полном закрытии доступа", а всего лишь о запрете на редактирование - я могу это добавить. Я видимо не так понял, о чем идет речь. Хорошо. Я добавлю такую возможность READONLY справочника. Это не проблема.

serge35 (15.04.04 15:37) [110]
Я не думаю, что 1С нуждается в передовых технологиях Аллегро.

А я разве говорил, что нуждается? Я всего лишь ответил на Ваше предположение, что эти две системы станут похожими. Не станут. Так как именно баланс-навигатор их отличает принципиальным образом. В 1C "План счетов" и "Баланс" - разные вещи. В Allegro это то же самое.

← →
serge35 (2004-04-15 16:22) [118]

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

Просьба к Кайфу - поменьше текста.

У меня в ядре нет такой таблицы
А вот тут ты не прав, друг мой. :-)
Уверен, что журнально-подобная таблица должна быть в системе,
где могу быть перечислены АйДишники документов и все эти твои
"поле даты", "поле номера", "поле суммы" и "поле примечаний" и пр.

← →
serge35 (2004-04-15 16:25) [120]

> В 1C "План счетов" и "Баланс" - разные вещи. В Allegro это то же самое.

Спасибо за разъяснение, а то я уже 10 лет не могу отличить План счетов от Баланса. Ооочень свежее замечание!

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