Форум: "Потрепаться";
Текущий архив: 2004.05.16;
Скачать: [xml.tar.bz2];
Вниз
Платформа Аллегро ... баннер перед носом ... чуть выше.. Найти похожие ветки
← →
Digitman © (2004-04-13 15:53) [0]Ваши впечатления ?
← →
LordOfSilence © (2004-04-13 16:13) [1]Очень и очень не дурно. Я смотрел ее и читал доку. Чувствуется,
что человек писал, зная дело и зная, что он хочет сделать.
Есть интересные идеи и задумки, не тяп-ляп.
← →
Awex (2004-04-13 16:17) [2]ИМХО:
Я думаю, продукт найдет заинтересованных в нем лиц и свою нишу...
Нишу конструкторов решений... Конечно при условии хорошей базы "готовых решений" и хорошей технической документации..
Использована стандартная проверенная связка:
DreamScript + VCL + InterBase.
Ну а дальше все зависит от грамотного маркетинга авторов..
← →
Тимохов © (2004-04-13 16:18) [3]Детально не смотрел - но меня пугает excel как основной движок визуализации отчетов.
Детально буду смотреть. Заявлено все очень интересно.
← →
MBo © (2004-04-13 16:28) [4]Надо kaif-а спросить ;)
← →
serge35 (2004-04-13 16:41) [5]Мда. А проблемка с постановкой задачи так и не решена.
1С уже 15 лет бьются над конфигурациями. Народу в этом задействовано немеренно.
А постановка сотрудничества по принципу - ты нам создай удачную конфигурацию, а мы ее будем продавать - напоминает лохотрон.
← →
Тимохов © (2004-04-13 16:53) [6]
> serge35 (13.04.04 16:41) [5]
Что вы имеете в виду?
Какая проблема не решена?
← →
serge35 (2004-04-13 17:04) [7]> Для нас ценна постановка задачи и эргономика. Если мы находим конфигурацию удачной, мы заключаем с разработчиком договор об интеллектуальной инвестиции.
>В этом договоре указывается, что разработчик передает проекту GAAPInvest права на использование данной постановки задачи и данного эргономического решения
>От разработчика требуется выполнение двух условий: он должен полностью поставить задачу и он должен реализовать работающую конфигурацию в Allegro
Что еще нужно для лохотрона?
← →
Digitman © (2004-04-13 17:15) [8]Ребятки, вопрос был не о "лохотроне") ... Здесь-то как раз все понятно ..
Платформа как таковая ?
Насколько реальна ее конкурентноспособность по отношению к 1С-платформе и аналогичным по идее ?
Надежность ? Гибкость ? Перспективность ? Вот о чем вопрос ...
← →
DiamondShark © (2004-04-13 17:18) [9]
> Какая проблема не решена?
Очевидно, имеется в виду вот эта:
Многие компании, разрабатывающие учетные программы на заказ, либо требуют уже готовое детальное техзадание от заказчика, либо отдельной оплаты за разработку такого техзадания. И часто стоимость такого техзадания составляет более 70% стоимости конечного программного продукта. При этом в каждой сфере бизнеса работает множество практически однотипных компаний, с очень сходной структурой бизнес-процессов. Это наталкивает разработчика, как впрочем, и заказчика, на мысль о том, что возможно написать некую «специализированную стандартную конфигурацию», которая подошла бы для всех таких фирм. Но из этого как правило ничего не получается. На то существуют две причины:
1. Часто заказчики на какой-то фазе «портят» программу, добавляя в нее специфические элементы, свойственные только их компании и по сути программа теряет признаки «простой и красивой программы для данного бизнеса».
2. Независимые разработчики программ обычно затрудняются осуществлять поддержку своих программ, особенно если их клиенты разбросаны по стране. Поэтому и надежды независимых разработчиков на тиражирование удачных программных решений не осуществляются.
http://www.gaapinvest.com/project/about.html
IMHO, таки да, не решена. И что-то мне подсказывает, что дело здесь не в используемых програмно-технических средствах.
← →
DiamondShark © (2004-04-13 17:24) [10]
> Ребятки, вопрос был не о "лохотроне") ... Здесь-то как раз
> все понятно ..
Что понятно? Таки, лохотрон? Или как?
← →
Тимохов © (2004-04-13 17:24) [11]
> Digitman © (13.04.04 17:15) [8]
У 1c нет конкурентов.
Она везде и стоит копейки (да можно и стырить).
К серьезной настройке и прозрачности деятельности (о возможности такой настройки написана на сайте allegro) никто из заказчиков не готов. Вернее активно против. Все что нужно - вести бухгалтерию, платить налоги и не получить по ж. за недоплату. Для этой цели прекрасно подходит 1с.
Если нужно сделать серьезную учетную систему, то тут совсем все по-другому: r3, baan или еще что, причем за совсем нешуточные деньги. Знаю, что настройка системы на одном из предприятий (не скажу какого, крупного) стоила не один млн д.
Мое резюме:
1. если владельцу нужен учет - он найдет деньги и людей, которые напишут ему систему на чем угодно, хоть, на дельфи и система будет решать ему именно ему нужные задачи.
2. чаще владельцу нужно отмататься от гос-ва по оплате налогов. Для этой цели идеально походит 1с для ведения бухгалтерии и туча программистов на этой системе, которые ему все сделают.
Одним словаом, на вопрос digitman о достоинствах обсуждаемой системы я не ответил. Но привел свою позицию, которая говорит о том, что никакая система (платформа) не родит желание у заказчика наводить у себя учет.
← →
serge35 (2004-04-13 17:26) [12]> IMHO, таки да, не решена. И что-то мне подсказывает, что дело здесь не в используемых програмно-технических средствах.
Совершенно согласен.
Дайте мне хорошее, развернутое ТЗ, в котором учтено ВСЕ, начиная от справочной системы, заканчивая последним отчетом и через несколько месяцев будет готовая программа.
Мало того, что они хотят получить готовую конфигурацию, они еще хотят получить исходный текст не заплатив ни за то, ни за другое ни копейки разработчику. А по этому договору, который заключаются с разработчиком ответят примерно так: "извините, но Ваша конфигурация оказалась не очень удачной, и продаж по ней нет" даже если конфигурация будет продаваться на Ура!
← →
Anatoly Podgoretsky © (2004-04-13 17:27) [13]Digitman © (13.04.04 17:15) [8]
Трудно сказать, ясно что не для конечного пользователя, здесь конкуренции 1С не составит, а вот для разработчиков вполне, будет зависить от маркетинга.
Мне известны системы, где рабочим местом разработчика (со стороны клиента) является Д5Про, база на MSSQL, естественно лицензионные, то есть клиенту предоставляется оба продукта и обучение персонала, программист не требуется, но желателен.
Разработан мощный комплект специализированных бизнес компонент, а не ориентированых на программиста. Пользователь (обцченный) в состоянии делать свои формы, отчеты, запросы, работает в ИДЕ Дельфи и компилируя полученную систему.
Стоимость системы начинается с 1 млн. деревянных.
Очень удачное решение.
← →
serge35 (2004-04-13 17:36) [14]Кстати про стоимость конфигурации для заказчика ни слова я не нашел.
← →
LordOfSilence © (2004-04-13 17:37) [15]Сейчас, к сожалению, нет времени это обсуждать, но на всякий случай уточню. Аллегро я смотред давно (примерно полгода назад), еще когда рекламы и в помине не было. Так вот, из частных разговоров с Ашотом, могу сказать, что он не позиционирует свой продукт как конкурент 1С в сфере фискального учета. Вообще он старается довольно аккуратно высказываться на эту тему, так как 1С в данный момент - это локомотив, уже набравший приличную скорость и тупо плеваться в ее сторону - это просто глупо. Насколько я понял из разговоров с ним, он желает сделать прозрачную технологическую платформу для построения управленческого учета, не заморачиваясь с отчетностью в фискальные органы. Примерно так.
← →
Digitman © (2004-04-13 17:48) [16]Дохотрон или не лохотрон - не это меня интересует ...
Проба платформы ? Реальная ?
← →
Digitman © (2004-04-13 17:56) [17]Я заинтересовался Аллегро совершенно случайно, буквально - в ближ. неделю-другую ... посмотрел-пощупал ... сравнил платформу с 1С-ной ... не могу сказать, что у меня остались искл-но отвратные впечатления ... скажу честно - направление и то что в нем сделано - мне весьма импонирует ... кратко, внятно, без дури и излишеств ... набор поддерживаемых скриптов - каким бы гон ни был, но той 1С-ной дури и в помине нет ... уже это приятно ..
← →
serge35 (2004-04-13 17:59) [18]А что платформа? Купил сервер, Delphi и пиши себе сколько влезет.
Oracle на мой взгляд лучше чем IB.
← →
Digitman © (2004-04-13 18:02) [19]Oracle - всего лишь контейнер в дан.случае .. imho ...
← →
serge35 (2004-04-13 18:04) [20]>система Allegro способна осуществить такой перенос данных независимо от конфигурации благодаря тщательно продуманной бухгалтерской модели и идеологии хранения данных
Если они используют FlexibleFields как сделано в Oracle Application - то это полная Ж...
← →
kaif © (2004-04-13 21:46) [21]О, кажется, обсуждают Allegro и проект gaapinvest.
Это не лохотрон. Это нормальная идея сотрудничества. Построенная на доверии, здравом смысле и взаимном интересе. И я надеюсь, что она заработает. Гарантией того, что мы не будем ничего "тихаря юзать" или скрывать продажи - можете считать мое честное слово. Я знаю, как соблюсти права разработчиков-инвесторов и как составить отчетность грамотно. Так, чтобы ни у кого не возникло вопросов или претензий. Более того, эта отчетность будет публичной и белой во всех отношениях.
Что касается эффективности Allegro, то она уже проверена на практике. Я давно пишу системы реального (не бутафорского) учета на заказ в среде Delphi. Так вот, с созданием Allegro, я полностью перешел на написание таких систем в Allegro, так как экономия времени колоссальная, а о гибкости - я уже не говорю. Очень важным оказалось то обстоятельство, что любую ошибку можно подправить прямо на месте (у заказчика), без остановки работы фирмы.
Я старался создать простой инструмент, в котором не было бы ничего лишнего и было бы все максимально прозрачно и доступно для SQL-щика.
К сожалению, документация пока все еще не полная. Но я ее постоянно дописываю и публикую.
Если есть вопросы - задавайте. Я постараюсь ответить на все вопросы.
С уважением.
← →
Юрий Зотов © (2004-04-14 00:00) [22]> kaif © (13.04.04 21:46) [21]
> Если есть вопросы - задавайте. Я постараюсь ответить на все
> вопросы.
Есть пара вопросов.
1. Хватает ли возможностей DreamScripter"а для реального написания реального кода? Скажем, DelphiScripter подддерживает не полный Object Pascal - так вот, хватает ли поддерживаемого подмножества?
2. Каким образом удалось обойти лицензионную проблему, связанную с необходимостью распространения DesignIDE.bpl?
Заранее благодарю.
← →
kaif © (2004-04-14 00:31) [23]2 Юрий Зотов © (14.04.04 00:00) [22]
1. В принципе возможностей DreamScripter-а, на мой взгляд, хватает. Дело в том, что Allegro работает с базой данных напрямую. Поэтому все искусство программирования скорее сводится к написанию хороших SQL-запросов и хорошей организации данных. А скриптер по большей части обслуживает лишь оконный интерфейс. Практически все обячные конструкции работают, например, блоки защищенных ресурсов try finally end, массивы, создание компонентов run-time. Конечно это не Object Pascal и там не напишешь новый класс. Но практически все функции, которые привык использовать разработчик, импортированы. Например, IntToStr, FormatDateTime, Format, DateToStr, MonthOf и многие другие.
2. Среда IDE DreamControls заново воссоздает среду, похожую на IDE Delphi. Там не используется двоичный код IDE Delphi. Редакторы свойств многих компонентов написаны заново (кроме некоторых). Если можете, расскажите подробнее о проблеме с распространением DesignIDE.bpl. Возможно, я не совсем точно отвечаю на Ваш вопрос. Я специально компилировал Allegro с run-time libraries и добивался того, чтобы ничего (даже случайно) из борландовских библиотек среды IDE туда не попало. Были проблемы при импорте некоторых компонентов. И мне пришлось заново написать некоторые редакторы свойств. Однако до конца ручаться за то, что я ничего не нарушаю (из прав на внешний вид), мне сложно. Например, мне неизвестно, может быть отображение объект-инспектора "в стиле Delphi" само по себе уже что-то нарушает... Лицензионные соглашения пишутся очень витиеватым языком и без специальной юридической экспертизы мне будет трудно что-то определенно утверждать. И финансов на такие исследования пока нет. Пока я рассчитываю на здравый смысл. Allegro не позволяет писать новые компоненты. Следовательно, главная мощь Delphi не затронута. Это просто скриптовая поддержка на уровне приложения. Если же будут претензии, то придется, конечно, утрясать какие-то детали с заинтересованными сторонами...
← →
kaif © (2004-04-14 00:41) [24]Привожу кусочек текста Allegro. В этом модуле реализованы редакторы свойств компонентов IBX и происходит регистрация этих редакторов свойств и самих компонентов.
unit ib_reg;
interface
implementation
{$IFDEF USE_ALLEGRORES_DLL} (*----------поддержка W98-----я добавил-------*)
{$ELSE}
{$R IBBMP.DCR}
{$ENDIF}
uses
Classes, SysUtils, Controls, Forms, Dialogs, db,
{dsgnintf,}
// DesignIntf, DesignEditors,
dcdsgnstuff,
typinfo ,
a_Fldlinks, a_sqledit, {эти 2 файла взяты из Property editors и переделаны для избавления от dblcb50.bpl}
IBIntf,
IBXConst,
IBTransactionEdit,
IBDatabaseEdit,
IBUpdateSQLEditor,
IBTable, IBQuery, IBStoredProc, IBDatabase,
IBUpdateSQL, IBCustomDataSet, IBSQL,
IBDatabaseInfo, IBSQLMonitor, IBEvents, IBExtract,
IBServices, {IBInstall,}
IBBatchMove, DBLogDlg, IBGeneratorEditor, IBUtils,
IBServiceEditor, IBRestoreEditor, IBSecurityEditor,
IBEventsEditor, IBDCLConst,
IB,
dctreeed, {Object Explorer for TIBDataSetBaseEditor.Edit}
treeinsp ;
Жирным я выделил ряд модулей библиотеки Dream Controls, которые занимаются регистрацией редакторов свойств компонентов или сами реализуют некоторые из них.
// DesignIntf, DesignEditors, (эти модули не используются!)
dcdsgnstuff, (вместо них используется вот это)
← →
kaif © (2004-04-14 01:05) [25]Так выглядит текст, который интерпретирует скриптер:
http://www.gaapinvest.com/allegro/doc/book2/doc047.html
Это учебный пример реализации склада в Allegro, который размещен на сайте в разделе "документация". Здесь можно видеть, какие конструкции понимает скриптер. Это очень похоже на обычную дельфийскую программу.
← →
Юрий Зотов © (2004-04-14 01:09) [26]> kaif © (14.04.04 00:31) [23]
Наверное, надо пояснить. То же самое и на той же связке я написал года 3 или 4 назад (только не как самостоятельный продукт, а в рамках другого продукта). Поэтому в курсе дел и вопросы вовсе не праздные.
Первый вопрос был вызван тем, что все это время Конструктор (будем называть его так) использовался, как Вы и говорите, именно SQL-разработчиками, но, насколько я знаю, Delphi-скриптов в нем пока еще не писали. То ли просто не было необходимости, то ли из-за недостаточной поддержки языка (хотя при тестировании я писал довольно развитый код и он работал). Это и хотелось выяснить.
Второй вопрос возник в связи с тем, что Borland не лицензирует DesingIDE.bpl для распространения. При компиляции в D5 это обходится легко (поскольку имеется Proxies.dcu, можно загнать весь код в Exe), но при переходе на D6-D7 возникает проблема. Dream Controls позволяет использовать опции UseVCLDesigner (использовать design-код VCL), либо UseOwnDesigner (использовать эмуляцию, о которой Вы говорите). Соответственно, в первом случае проект требует Proxies (которого уже нет, а dcp к проекту не прицепишь, это не пакет), а во втором мне не удалось добиться безглючной работы некоторых редакторов свойств и компонентов (хотя в "родной", а не эмулированной среде они работают безукоризненно).
← →
kaif © (2004-04-14 01:41) [27]2 Юрий Зотов © (14.04.04 01:09) [26]
Вы правы насчет некоторых глюков собственного дизайнера DreamControls. Многие из них (самые вредные) я искоренил, исправляя их исходный код. Некоторые до сих пор остались. Например, такой экзотический глюк: после присвоения в инспекторе объектов свойства Action новому (только создаваемому) пункту меню это присвоение самым таинственным образом теряется. Но присвоение происходит нормально, если этот пункт меню не новый. Однако работе в общем и целом это мало мешает. Есть гораздо более важные проблемы, которые мне пока не удалось никак решить. Например, я до сих пор толком не знаю, как реализовать "снятие с исполнения" бесконечного цикла в скрипте (например, если разработчик случайно написал и запустил такой цикл).
К тому же нужно будет, возможно и с трудом, встраивать пошаговый отладчик (пока он не встроен и даже не приобретен у Dream Company). Хотя пока без него разработчики обходятся.
Таким образом, у пакета DC есть свои плюсы и минусы, но когда я начинал эту работу (3 года назад) у меня не так широк был выбор... Сравнив все на тот момент времени, я пришел к выводу, что DC - то, что мне нужно. Он легко развивал 1 млн. операций сложения в секунду при поддержке огромного количества нужных мне функций. Для сравнения на той же машине интерпретатор 1С развивал всего 150 тыс операций при своих гораздо более скромных возможностях.
Я постоянно шлифую Allegro. Так что существующие глюки постепенно будут вылавливаться и исправляться.
← →
kaif © (2004-04-14 02:05) [28]2 All.
Мне прислали справедливые нарекания на то, что на сайте не была указана цена на Allegro.
Сообщаю, что цена теперь указана.
http://www.gaapinvest.com/project/shemeuse.html
← →
kaif © (2004-04-14 04:56) [29]2 serge35
Попытаюсь объяснить, почему проект gaapinvest - не лохотрон. Возможно, я слишком спешил с сайтом и неясно обрисовал идею на странице "О проекте".
1. Разработчик и так имеет возможность тиражировать и продавать свою удачную конфигурацию. Таким образом, мы никак технически не принуждаем к участию в проекте gaapinvest. Однако в этом случае обязанность по поддержке покупателей лежит на разработчике. Просто нам трудно гарантировать совместимость версий, если у нас нет сведений о существовании такой конфигурации и нет контроля над ней.
2. Почему нам невыгодно кого-то кидать или динамить? Да просто потому что чем больше копий Allegro работает у клиентов, тем больше торговая марка Allegro усиливает свое влияние. На сегодня весь успех предприятия целиком и полностью зависит именно от массовости использования этой платформы конечными юзерами. Если они будут покупать стандартные конфигурации, то мы в любом случае выигрываем. Если же мы "кинем" кого-то из разработчиков, то мы теряем свое лицо в такой степени, что это эквивалентно провалу всей идеи. К тому же только на стандартных конфигурациях могут вырабатываться универсальные требования к тому, что в Allegro следует еще добавить.
3. Почему разработчикам выгодно иметь с нами дело в тиражировании стандартных конфигураций? Потому что мы можем осуществлять централизованную поддержку и его клиенты в любом случае будут больше доверять нашей поддержке, нежели его поддержке (по тем причинам, что я описал ранее в п.1). Учтите, что система Allegro развивается и кое-что в ней изменяется. И наша поддержка обойдется дешевле и ему и его клиентам. Не говоря уже о том, что перечень "стандартных конфигураций" и их свойства будут централизованно публиковаться на нашем сайте. А наш сайт будет рекламироваться. Нам в любом случае легче будет продавать этот тираж, чем разработчику. И наконец, разработчик стандартной конфигурации вправе не приобретать Allegro вообще, а вести разработку в Демо-версии. В отличие от разработчика, ведущего разработку на заказ. А если он совмещает эти две функции, то мы готовы продавать ему Allegro в кредит, так как этот кредит обеспечен его участием в проекте gaapinvest. Кто еще предлагает такие условия для разработчиков?
Технология наших "апдейтов" следующая. Все разработчики и пользователи будут получать уведомление о необходимости апдейта. Апдейт состоит в переустановке системы Allegro "поверх имеющейся". Если в ядро базы нами что-то добавляется, то перед коннектом с каждой "старой" базой появится предложение о необходимости автоматического апдейта ядра. Эта технология уже отработана. Мы так уже повышали версию ядра с 1.1 до 1.2 и 1.3. Апдейт кумулятивный. Перед апдейтом автоматически делается резервная копия старой версии.
Одним словом, мы намерены использовать практику более или менее синхронных апдейтов. Чтобы все экземпляры Allegro были идентичными у всех разработчиков и юзеров.
Стоимость стандартной конфигурации может быть существенно ниже стоимости Allegro. Например $150-300. Разумеется, все зависит от того, что это за конфигурация и насколько она востребована. Более массовая и типовая конфигурация будет продаваться дешевле. Уникальная и рассчитанная на очень специфическую сферу - дороже.
Не обязательно, чтобы это были какие-то очень сложные конфигурации. Как раз лучше, если они будут простыми и понятными, не требующими усиленного изучения. Желательно, чтобы справочники были уже хоть немного заполнены данными, вызывающими эффект узнавания. Для многих задач несколько интерфейсов-документов вроде цепочки "от заказа до исполнения" плюс несколько хорошо продуманных (под сферу) справочников - будут отлично смотреться, а покупатели будут довольны, так как у них сейчас как правило вообще ничего нет, кроме Excel и кучи бумаг на столах. Каждая такая конфигурация потенциально создает работу будущим разработчикам уже "на заказ" для тех юзеров, которые захотят что-то "добавить" или "усовершенствовать".
← →
Digitman © (2004-04-14 11:13) [30]
> kaif
мне непонятно отсутствие в меню и тулбаре панели Метаданные/Справочники элементов управления созданием/редактированием Рубрикаторов ..
в контекстной справке Аллегро описание механизма управления рубрикаторами фигурирует, однако ни в контекстных меню ни тулбаре нет ни намека на сабж ... нет этого и в http://www.gaapinvest.com/allegro/doc/book3/doc015.html
как сие понимать ? рассматривается платф.версия 1.3.0.2
← →
serge35 (2004-04-14 11:34) [31]> Поэтому все искусство программирования скорее сводится к написанию хороших SQL-запросов и хорошей организации данных
По-моему это относится ко всем базам и языкам программирования.
Если бы была создана система, в которой ядро т.е. база данных спроекирована так, что больше никакая дороботка в ей не нужна, тогда я был бы обеими рукам ЗА!
А парить мозги пользователям у которых
> как правило вообще ничего нет, кроме Excel и кучи бумаг на столах
Это можно с помощью 1С.
← →
Anatoly Podgoretsky © (2004-04-14 11:51) [32]Это можно с момощью гигантской кучи продуктов, включая очень дорогие. Вопрос то не стоит об том, есть другие продукты или нет, а что собой представляет данный продукт, что он может, насколько хорошо, стоят ли вложения в него или нет.
Есть ли более лучшая альтернатива при тех же вложениях или данный продукт вне конкуренции в своей нише.
Очень важно кроме достоинств также знать и недостатки, ограничения, более важно чем достоинства.
← →
Digitman © (2004-04-14 12:02) [33]
> Anatoly Podgoretsky © (14.04.04 11:51) [32]
> что собой представляет данный продукт, что он может, насколько
> хорошо, стоят ли вложения в него или нет.
именно !
вот один непонятный пока глюк мне уже виден).. см. [30]
← →
serge35 (2004-04-14 12:10) [34]писать лучше на языке, в котором ты абсолютно уверен.
А все эти надстрийки над языками, "облегчающие" жизнь зачастую оборачиваются "медвежьей услугой"
Наша компания продает Pivotal. Мне предложили заниматься ее кастомизацией. Я отказался, не смотря на то, что кастомизация предполагает загранкомандировки.
← →
kaif © (2004-04-14 12:26) [35]2 Digitman © (14.04.04 11:13) [30]
Каюсь. Help очень старый.
Я исключил рубрикаторы из ядра системы Allegro. Это не глюк.
Help будет сделан заново на основе описания UserManual, которое пока полностью не готово.
← →
Digitman © (2004-04-14 12:41) [36]
> kaif © (14.04.04 12:26) [35]
> Я исключил рубрикаторы из ядра системы Alle
почему ? с чем это связано ? imho, чрезвычайно удобная и полезная штука !
представь себе, например, необходимость формирования в ран-тайм конечным юзером дерева категорий товарной номенклатуры, где с каждым узлом ассоциирована группа элементов того или иного номенкл.справочника, т.е. каждая подгруппа в дереве("субкатегория") объединяет несколько номенкл.единиц по некой комбинации их атрибутов ..
← →
kaif © (2004-04-14 12:48) [37]2 serge35 (14.04.04 12:10) [34]
На сегодня сложились 2 направления:
1. Приближение систем "к юзеру". Чтобы тот мог сам создавать "формы документов", добавлять "таблицы" и так далее. Это подкупает юзера и повышает конкурентоспособность продукта. На мой взгляд этот подход и есть "впаривать". Так как юзер, не знакомый с принципами нормализации и не придающий значения таким вещам, как уникальность, к примеру, обречен нагородить нечто несусветное, а затем приползти на коленях к программисту.
2. Удовлетворение запросов программиста-профессионала. Это серьезные и дорогие системы. Та же Delphi, к примеру. Или мощная CASE + Delphi + ORACLE за несколько десятков тысяч долларов. Такие системы хороши для дорогих проектов, чем обычно "конфигурирующие фирмы", по большей части и занимаются.
Я пытаюсь еще раз решить ту задачу, которую ставили вначале (как мне кажется) создатели 1С: удобное и недорогое средство для профессионала, позволяющее независимым программистам зарабатывать хорошие деньги, а юзерам быстро получать надежные и недорогие программы, приспособленные под их бизнес.
Можно "впаривать", а можно и не "впаривать". Это, так сказать, дело вкуса и уважения к своим заказчикам. От платформы это никак не зависит. В 1С тоже иногда пишутся дельные вещи. Вопрос в том, за какое время и какими усилиями. И с какой скоростью потом все это работает. И сколько народу (бухгалтеров и программистов) затем требуется, чтобы это работало (совокупная стоимость владения).
← →
Danilka © (2004-04-14 12:56) [38]
> В 1С тоже иногда пишутся дельные вещи. Вопрос в том, за
> какое время и какими усилиями.
Кстати, намного быстрее и проще, чем то-же самое, например, на дельфях.
Правда, вот с этим:
> И с какой скоростью потом все это работает.
Бывают проблемы, и то не всегда.
Все зависит только от людей. Я знаю очень хороших специалистов 1С, чьи конфигурации работают с базами на сотни мегабайт, и даже есть за гигабайты.
Надеюсь, у Аллегро с производительностью проблем будет меньше, раз запросы к СУБД можно самим писать.
Кстати, а в кредит он будет продаваться?
И еще, где можно посмотреть версию, я ее смотрел давно очень, файл AllegroSetup.exe от 28 октября, как я понимаю, есть более свежая версия?
← →
serge35 (2004-04-14 13:02) [39]И что, пользователь, знакомый только с Excel сможет самостоятельно спроектировать базу данных?
И какова же окажется окончательная стоимость проекта, на котором программисты смогут заработать "хорошие деньги"?
И как в таком таком случае получится "Недорогая и надежная программа" для пользователя.
Давайте посчитаем по себестоимости. Допустим один рабочий день программиста, работающего на заказ стоит 50$.
Предположим, что для разработки конфигурации требуется 3 месяца, т.е. 60 рабочих дней.
Таким образом конфигурация обойдется в 3000$
Не так уж и дешево.
С таким же успехом можно нанять программиста на постоянную работу, а не пользоваться услугами приходящих и уходящих.
К тому же простите надо купить лицензию на Delphi и IB.
Да еще заплатить за Allegro.
← →
Digitman © (2004-04-14 13:08) [40]
> kaif
1. Планируется ли тобой версия платформы для организации 3-звенки ?
2. Извини, у меня не было выбора - демо-движок (то что выложено на сайте) пришлось сломать, чтобы воочию оценить произв-ть операций на значительно больших (>> 1000 записей) наборах данных .. ч.г., мне не очень понравилась производ-ть при массированной вставке-модификации в справочники и документы ... тестировал на FB1.5 RC9 ... где-то, очевидно, есть "узкие места", возможно - в не слишком удачной логике управления транзакциями при таких вот операциях ... не думаю на это как-то влияиет RC9 vs RC4
← →
kaif © (2004-04-14 13:12) [41]2 Digitman © (14.04.04 12:41) [36]
представь себе, например, необходимость формирования в ран-тайм конечным юзером дерева категорий товарной номенклатуры, где с каждым узлом ассоциирована группа элементов того или иного номенкл.справочника, т.е. каждая подгруппа в дереве("субкатегория") объединяет несколько номенкл.единиц по некой комбинации их атрибутов ..
К сожалению, это именно то, что я не посчитал благом.
Потом юзер приходит и просит сделать отчет "по категориям". А там чего только нет:
СПРАВОЧНИК ТОВАРОВ:
Ботинки мужские
Черный цвет
...
Возврат от 10.01.2003
Ботинки женские
Черный цвет
Передано под отчет Васе (партия из 10 пар)
Китай
...
Брак
Чулки женские
...
Деньги наличные (отдали за транспорт в Саратов)
Другое
Остатки на складе на 02.03.2004
-------------------------------
То есть если дать неформализованное "просто дерево" юзеру, то начинается смешение сущностей и совершенно несовместимых понятий. Я не придумываю. Это одна из постоянных болезней справочников 1С. Юзеры не видят причин, по которым в справочник товра не может попасть, например, такая позиция, как "возврат денег" или категория "остатки на такое-то число".
-------------------------------
Если конфигурирующий обязательно хочет реализовать рубрикаторы, он может это реализовать своими средствами (вручную). У него прямой доступ ко всем таблицам. И достаточно оконных компонентов. Провоцировать его на рубрикаторы специально я пока не решился. Рубрикаторы снимают головную боль с программиста и приносят большую радость юзерам. Но потом чудовищный результат для учета и кошмар для программиста (если он не сбежит к тому времени).
-----------------------------
Что касается принципиальной возможности делить по категориям, почему бы не создать пару обычных справочников? Возможно, у меня недостаточное управление справочниками. Например, если бы можно было после выбора значения поля "категория" сужать список "подкатегорий" (второе поле в "трехуровневой" жесткой модели), то, возможно, это решало бы ту задачу, которая стоит в основе проблемы. Если усовершенствовать интерфейс линейных справочников для "какого-то древовидного отображения", то в каких-то случаях это может быть оправдано.
Но если я предоставлю юзеру дерево "как таковое" - потом SQL-щики меня проклянут. А именно этого я бы не хотел.
← →
Digitman © (2004-04-14 13:39) [42]
> kaif © (14.04.04 13:12) [41]
все что ты говоришь - верно, я не спорю) ... ран-тайм-смешение юзером сущностей в такого рода справочниках - действительно большая головная боль для программеров и тех кто сопровождает конфигурацию .. но и этот вопрос вполне решаем на уровне платформы !
> если я предоставлю юзеру дерево "как таковое" - потом SQL-щики
> меня проклянут
введи design-time-опцию "использовать механизм рубрикаторов" .. или "предоставить юзеру интерфейсный доступ к ран-тайм-управлению рубрикаторами" ... пусть программер, пишуший прикл.конф-цию, сам принимает решение о допустимости или недопустимости предоставления интерфейса рубрикаторов конечному юзеру !
а есть ли возможность посмотреть демо платформы, где рубрикаторы еще "живы" ? хочу таки своими мозгами оценить, во что это выльется в реалии ... был бы премного благодарен ...
← →
kaif © (2004-04-14 13:47) [43]Danilka © (14.04.04 12:56) [38]
> В 1С тоже иногда пишутся дельные вещи. Вопрос в том, за
> какое время и какими усилиями.
Кстати, намного быстрее и проще, чем то-же самое, например, на дельфях.
Правда, вот с этим:
> И с какой скоростью потом все это работает.
Allegro позволяет писать так же быстро, как в 1С и даже намного быстрее, так как не требует переключения в "конфигуратор" и обратно и монопольного захвата каждый раз. А результат - сопоставимый с Delphi (по скорости и интерфейсам).
Кстати, а в кредит он будет продаваться?
Да, будет.
И еще, где можно посмотреть версию, я ее смотрел давно очень, файл AllegroSetup.exe от 28 октября, как я понимаю, есть более свежая версия?
На форуме реклама (наверху). На сайте всегда есть свежая версия. О продажах там тоже подробно написано.
serge35 (14.04.04 13:02) [39]
И что, пользователь, знакомый только с Excel сможет самостоятельно спроектировать базу данных?
Нет, не сможет. Но если он знаком с базами данных и нормализацией, то сможет создать Метаданные. Для программиста останется разобраться с интерфейсом. Система и не пытается "косить" под пользователя. Она изначально заточнена под программиста - дельфиста.
И какова же окажется окончательная стоимость проекта, на котором программисты смогут заработать "хорошие деньги"?
И как в таком таком случае получится "Недорогая и надежная программа" для пользователя.
Давайте посчитаем по себестоимости. Допустим один рабочий день программиста, работающего на заказ стоит 50$.
Предположим, что для разработки конфигурации требуется 3 месяца, т.е. 60 рабочих дней.
Таким образом конфигурация обойдется в 3000$
Не так уж и дешево.
Разработка занимает 1 месяц (20 рабочих дней по $50) и стоит, таким образом, $1000. Не так уж и дорого. Именно на этих условиях я писал первую конфигурацию в Allegro.
К тому же простите надо купить лицензию на Delphi и IB.
Да еще заплатить за Allegro.
Покупать Delphi не нужно, так как allegro не содержит в себе (даже замаскированного) кода IDE Delphi. Покупать IB тоже не нужно, так как Firebird бесплатен. Желающие могут купить Yaffil. Он стоит $200. Или могут подождать Firebird 2.0. В него войдет код Yaffil.
Покупать Allegro конечному пользователю (заказчику) тоже не нужно. Allegro нужно купить разработчику (программисту). Так что заказчик платит только за работу, а Allegro (как исполняющую систему-интерпретатор) получает даром. Если только он не собирается "сам заниматься конфигурированием". Итого, разработка конфигурации на заказ $1000. Это ориентировочная цена. Не так уж и дорого.
Есть проекты (совсем маленькие), которые, например, я берусь сделать за неделю и выставляю цену около $200-$300. Согласитесь, что это вообще недорого. Разумеется, многое зависит от опыта и искусства программиста.
← →
Digitman © (2004-04-14 13:51) [44]
> kaif
я вот себе думаю так : если юзеру в соотв-вии с его должн.инструкцией даны права-обязанности по ран-тайм-формированию некоего рубрикатора, определяющего конкретного рода связанные по логике сущности, то бардак в этом дереве целиком и полностью лежит на его совести .. конфигурирующий программер, imho, не несет ответственности за несуразность вводимых юзером в дерево данных
напротив, если у юзера есть хоть какая-то голова на плечах, то механизм и интерфейс рубрикаторов дает возможность резко повысить производительность работы юзера, автоматизировать множество операций по работе с подчиненными классификаторами и минимизировать ошибки ввода
← →
kaif © (2004-04-14 13:55) [45]Digitman © (14.04.04 13:39) [42]
а есть ли возможность посмотреть демо платформы, где рубрикаторы еще "живы" ? хочу таки своими мозгами оценить, во что это выльется в реалии ... был бы премного благодарен ...
Я постараюсь найти эту старую версию. Но она очень старая... Там вводилось сколько угодно рубрикаторов и было поле типа "рубрикатор". Если справочник содержит такое поле - слева возникало дерево в интерфейсе справочника. Один справочник мог содержать несколько альтернативных рубрикаторов. Я не исключаю, что в будущем какое-то может быть более умное решение с рубрикаторами мне удастся найти, если разработчики будут сильно жаловаться на отсутствие рубрикаторов. Но "старт" Allegro во внешний мир я решил дать без излишеств. Чем проще программа в момент рождения, тем больше вероятности, что ее кто-то попробует использовать. Я больше всего боялся создать мертвого монстра с "кучей возможностей". :)
← →
serge35 (2004-04-14 14:09) [46]А кто платит за составление ТЗ на конфигурацию?
И кто ее составляет.
В посте 12 я уже писал, что разроботка системы с 0 по готовому, проработанному ТЗ не составляет большого труда и не занимает много времени. Вопрос в том, что я лично таких ТЗ на большие системы не встречал. ТЗ на небольшие модули есть, я и сам их писал.
Я бы предпочел в качестве СУБД - Oracle и PL/SQL, да и многие потенциальные покупатели, которые собираются развивать и совершенствовать свою систему прекрасно понимают, что на средствах разработки экономить нельзя. В дальнейшем это выйдет боком.
Люди сейчас готовы заплатить десятки тысяч долларов, но они должны быть уверены, что система будет отвечать всем их требованиям и амбициям.
А в этой фразе уже заложено ограничение для разработчиков:
> если я предоставлю юзеру дерево "как таковое" - потом SQL-щики
> меня проклянут
Зачем мне такое средство разработки, если я не могу на нем сделать Фичу, за которую заказчик готов выложить немалые деньги?
← →
kaif © (2004-04-14 14:11) [47]2 Digitman © (14.04.04 13:51) [44]
Переложить ответственность на юзера всегда можно, но потом головная боль опять будет у программиста...
Приведу еще один аргумент против рубрикаторов. Существуют фирмы, торгующие алкоголем. У меня товарищ-ларечник работал с такой фирмой. У них такой рубрикатор (1С):
Литраж
Завод-производитель
Вид товара
Марка
Так вот. Заказ у такого поставщика занимает 20-40 минут. Сообщать девочке нужно именно в такой последовательности, в какой она будет открывать папки:
0.7 литра, Кристалл, водка, Гжелка
и так далее.
На поиск каждого товара по такой системе уходит уйма времени. Это реальные потери рабочего времени и они имеют стоимостное выражение. Для сравнения при поиске "по вхождению" в таблице сборных наименований, который обячно используется в Allegro, нужно нажать всего несколько клавиш:
7 гж
И вылезут все Гжелки 0.7 литра.
Я исхожу из следующих соображений. Допустим имеется 10тыс товаров. Один из 10 тыс - это всего 14 бит информации. Каждое нажатие на клавиатуре я оцениваю в 4-5 бит (букв и цифр всего 30-40). Следовательно, любой товар должен быть найден 3-4 нажатиями клавиш. И без всяких мышей. Если пользователь должен нажимать больше клавиш - интерфейс неправильный. Тогда пользователь предпочтет создать и запоминать коды товаров. Коды будут содержать 4 цифры, а он - искать по коду.
Рубрификации хорошо подвергать однородный материал. Например, документы в Allegro лежат "в папочках". А если у нас имеются классы товаров, то это может прийти в противоречие с системой рубрификации (еще одна проблема).
Я не спорю окончательно. Я спорю против рубрикаторов на данном этапе. Когда пользователь вообще еще не работал с классами. И предпочтет рубрикаторы "по инерции". Тогда пусть берет 1С и не заморачивается на строгую аналитику по группам. Но он же хочет эту аналитику! Как тут быть?
← →
serge35 (2004-04-14 14:29) [48]Начнем с того, что заказчик обычно сам не знает чего хочет.
Какие его действия? Он берет одну демо-версию и смотрит что его устраивает, а что нет. Затем, помотрев десяток демо-версий понимает, что целиком и полностью его не устраивает ни одна из систем.
Тогда он находит программиста и говорит ему, что ему нужна система такая, чтобы часть была из одной, вторая часть из другой системы и чисто от себя он хочет еще парочку наворотов.
И чтобы все работало. А на своем рабочем месте он хотел бы иметь одну больщую кнопку, чтобы нажав на нее он видел бы все, что твориться в его конторе.
← →
Danilka © (2004-04-14 14:34) [49][48] serge35 (14.04.04 14:29)
Мой опыт говорит о другом.
Как правило, заказчику просто некогда смотреть всякие демо-версии. И он просто говорит чего ему надо от программы.
Часто потом он говорит что это его не устраивает и надо немного по-другому, такую лажу надо стараться свести к минимуму и заранее обговорить стоимость работ по изменению.
← →
Digitman © (2004-04-14 14:41) [50]
> У них такой рубрикатор
ну дебильный же он, этот "пиво-водочный рубрикатор" !... извини за выражение)
по рукам надо дать тому, кто формировал конф-цию, позволяющую создать такое ...
атрибуты
Литраж
Завод-производитель
Марка
Градус
должны быть атрибутами элемента плоского номенкл.справочника, по которому, собственно, и производится выборка
а рубрикатор в этом случае д.б. выглядеть, наверно, примерно так
Категории (виды) алк.продукции
Крепкие алк.напитки
Водка
Коньяк
Шнапс
Косорыловка
Табуретовка
и т.п.
тогда выборка для отчетности выглядела бы так :
ВЫБРАТЬ из "Категории\Крепкие напитки\Водка"
ВСЕ изделия
ГДЕ
Завод-производитель = "ЧП Пупкин и Ко" И
Марка = "Андроповка" И
Градус = "Мало не покажется"
← →
serge35 (2004-04-14 14:42) [51]Интересно, сколько надо еще постов написать, чтобы донести одну простую мысль: На современном этапе эволюции средств разработки ПО этих средств разработано уже более чем достаточно. Проблема сейчас сводится к ПРАВИЛЬНОЙ ПОСТАНОВКЕ ЗАДАЧИ.
← →
Тимохов © (2004-04-14 14:44) [52]
> serge35 (14.04.04 14:42) [51]
Да с этим никто не спорит. Насколья я понимаю digitman и kaif в основном обсуждают конкретную платформу - ее достоинства и недостатки.
← →
Danilka © (2004-04-14 14:48) [53][51] serge35 (14.04.04 14:42)
> современном этапе эволюции средств разработки ПО этих средств
> разработано уже более чем достаточно.
да ладно?
а какой критерий достаточности?
← →
serge35 (2004-04-14 14:51) [54]> ну дебильный же он, этот "пиво-водочный рубрикатор" !... извини за выражение)
по рукам надо дать тому, кто формировал конф-цию, позволяющую создать такое ...
атрибуты
Литраж
Завод-производитель
Марка
Градус
Не так уж это и неправильно.
Если подходить с точки зрения что "система должна уметь угодить всем", то это очень правильный подход.
Я не даром спрашивал об использовании Flexible Fields.
Вместо того, чтобы добавить поле в таблицу и переделать несколько форм и несколько отчетов. Можно все атрибуты вынести в отдельную таблицу и при необходимости их добавлять для каждой категории товара. Это очень удобно, правда в таком случае создается огромное количество связей много-ко-многим между названием номенклатуры и его атрибутами.
Но ничего, SQL-щики разберутся...
← →
Тимохов © (2004-04-14 14:52) [55]
> Danilka © (14.04.04 14:48) [53]
на дельфи можно написать все что угодно - было бы задание.
согласен в serge35 - самое главное получить задание.
Моя контора также занимается разработкой платформы учетной финансовой системы, правда, пока только для наших заказчиков. Возможно в дальнейшем вылезем в люди. Мой опыт говорит возможность настройки (особенно пользователям) - беда для жизни системы. Заниматься доработкой или настройкой должен только квалифицированный программист.
← →
serge35 (2004-04-14 14:56) [56]>а какой критерий достаточности?
Критерий очень простой.
Одному достаточно одной платформы разработки для решения всех поставленных задач.
Другому для этого недостаточно и 10.
← →
Danilka © (2004-04-14 14:56) [57][55] Тимохов © (14.04.04 14:52)
и что?
например, на асме можно написать ровно столько-же сволько и на дельфях. :))
для меня сейчас самое главное - скорость разработки. а он у стандартного дельфи далеко не самый высокий по сравнению с другими системами.
← →
serge35 (2004-04-14 14:58) [58]> для меня сейчас самое главное - скорость разработки
Учись быстрее печатать.
← →
Irogen (2004-04-14 15:02) [59]Весьма недурно.
← →
Danilka © (2004-04-14 15:03) [60][58] serge35 (14.04.04 14:58)
> Учись быстрее печатать.
глупость какая. :))
в таком случае, могу почсоветовать Вам учиться быстро бегать, вместо того чтобы пользоваться каким-либо транспотром.
К тому-же я слишком для этого ленив - "печатать быстрее". :))
← →
Dmitriy O. © (2004-04-14 15:24) [61]Эксель самая крутая система учета и анализа.
← →
Тимохов © (2004-04-14 15:24) [62]
> Danilka © (14.04.04 15:03) [60]
> [58] serge35 (14.04.04 14:58)
не глупость.
скорость разработки в дельфи весьма приличная.
быстрее только кошки родятся.
было бы задание.
Могу сказать свое имхо.
Утв1: если есть задание точное и непоколебимое, то быстрее дельфи ничего нет (по крайней мере сильно быстрее).
Утв2: чаще заданий нет. В этом случае на помощь приходят весьма простая в использовании системы, которую на основе проб и ошибок могут настраивать все те же продвинутые пользователи (это еще этап проектирования, а не эксплуатации). К такому использованию платформы отношусь с пониманием - родить задание с нуля сложно, итерациями дойти до нужного понимания легче (я считаю, что это единственный путь).
У нас так и есть. Но! Все что в итоге понастроили продвинутые пользователи способно привести в ужас любого.
Вывод (для меня он непоколебим):
конечный продукт должен быть написан на НОРМАЛЬНОМ языке, но в системе обязательно нужна платформа, которая дает возможность продвинутым пользователям понимать, что они хотят посредтвом принятия участия в разработке. В результате настройки платформы нормальные квалифицированные программеры получают задание (весьма замечу точное) и переведя скриптовый язык (исправив по ходу кучу ошибок) в дельфи получаем хороший конечный продукт.
У нас примерно так и есть.
← →
Тимохов © (2004-04-14 15:25) [63]
> Эксель самая крутая система учета и анализа.
lmd
самая крутая система - это голова (своя)
← →
Danilka © (2004-04-14 15:34) [64][62] Тимохов © (14.04.04 15:24)
> Утв1: если есть задание точное и непоколебимое, то быстрее
> дельфи ничего нет (по крайней мере сильно быстрее).
Ну-ну. Учет и отчетность чего-либо на 1С-ке, получается делать иногда на порядок быстрее. Плюс к этому - стандартный интерфейс и легкость связи с бухгалтерией и проч. Kaif утверждает, что скорость разработки в Аллегро сопоставима с 1с-кой, возможно это и так, это я еще проверю. :))
> Утв2: чаще заданий нет.
А как браться за задание, если его нет? Не понимаю. Вообще, значительное время уходит на разработку ТЗ. А сама разработка только потом.
И еще, что значит "Нормальный язык", этого мне не понятно. Например, фокс-про, нормальный язык? А сколько было на нем написано еще под ДОС. На моей памяти, в налоговой работали системы за сотню пользователей с базами в сотни мегабайт.
← →
Тимохов © (2004-04-14 15:41) [65]Данил, не надо придираться к словам.
Нормальный - это тот язык где профи может все сделать профессионально, т.е. отвечать за резульатат.
Браться без задания? Вы слышали что-нить про эволюционную парадигму развития продукта? За частую в самом начале известно очень мало - даже заданием назвать сложно. Задание конкретизируется в ходе работы. Поймите мысль, что если такой путь применять при разработке на дельфи, то будет не очень хорошо. Лучше всего иметь платформу, дать на ней поиграться пользователю сто раз переделывая одно и то же, и потом сделать на нормальном языке надежно и устойчиво. Думаю ясно, что хочу сказать...
← →
Digitman © (2004-04-14 15:45) [66]
> Dmitriy O
ты еще не побывал на http://www.lleo.aha.ru/na ?
кажется, Игорь тебя очень конкретно адресовал ... с учетом еще и текущих твоих комментариев - оч и оч конкретно ... займись лучше "набором команды"
← →
Dmitriy O. © (2004-04-14 15:53) [67]
> Digitman © (14.04.04 15:45)
У нас на заводе один умелец соорудил на Access+Excel такую крутую систему учета и анализа брака. Что наши асушники не могли за два года разработки на Билдер C++ сделать лутше.
← →
Danilka © (2004-04-14 15:58) [68][65] Тимохов © (14.04.04 15:41)
> За частую в самом начале известно очень мало - даже заданием
> назвать сложно. Задание конкретизируется в ходе работы.
Ну, вообще-то да. Но это уже другой класс систем. Заключайется долгосрочный контракт, который оплачивается поэтапно.
Например, фирма Х делает для Y корпоративную систему под орокол, в которой более 600 таблиц и более 900 вьюх. Делается это в своей самописной (на дельфи правда) системе. Причем, если-бы абсолютно все делалось на дельфи, то было-бы затрачено на намного больше времени. А сейчас скорость разработки намного выше. Когда одних только отчетов свыше тысячи - сколько надо людей чтобы все это в квик-репорте нарисовать? Под это дело написана система позволяющая делать отчеты на порядок быстрее, или даже еще быстрее, конечно со своими ограничениями, под которые не попало, допустим, 10% отчетов.
← →
Тимохов © (2004-04-14 16:04) [69]
> Danilka © (14.04.04 15:58) [68]
Вы хото про себя?
Если да, то у нас примерно так же...
← →
Danilka © (2004-04-14 16:05) [70]Когда небольшая какая-то разработка, то заказчик знает чего он хочет. Правда, далеко не всегда он может это объяснить, и выудить у него все это - тоже очень нужное умение.
Лучше сначала как можно больше узнать, что конкретно надо, нарисовать примерно формы, перечислить все поля, во всех справочниках/док-тах, взять образцы бланков, и только потом начинать писать.
А на чем писать - от этого зависит скорость разработки, когда ты закончишь, а значит и стоимость системы. Чем выше скорость, тем меньше стоимость разработки, тем больше заказчиков к тебе обратится :))
← →
Danilka © (2004-04-14 16:06) [71][69] Тимохов © (14.04.04 16:04)
И что, неужели абсолютно все на дельфи? :))
← →
serge35 (2004-04-14 16:08) [72]Я писал и на FoxPro (DOS) и на Excel.
Помню, году эдак в 1995, когда Ельцин отменил 3 незначащих ноля у рубля, ко мне пришли знакомые, у которых стояла 1С и слезно умоляли убрать у них в базе эти нули за предыдующий год.
Я взял у них DBF-ки, разобрался и меньше чем за час написал прогу на Фоксе, которая удаляла эти нули.
Тогда 1С была самой защищенной программой. Но это только для бухгалтеров.
Не даром Билл купил FoxPro - это был язык, который мог составить конкуренцию VB.
← →
Danilka © (2004-04-14 16:10) [73][69] Тимохов © (14.04.04 16:04)
У нас в конторе, целая система написана, одних *.pas - файлов на 40 мегабайт, зато теперь полностью сосредотачиваешься на sql, я дельфи на работе не запускал уже бог знает когда - возможностей системы уже на все хватает.
← →
Digitman © (2004-04-14 16:12) [74]
> Dmitriy O. © (14.04.04 15:53) [67]
ой ну тебя, клоун ! со своим "заводом" ! заводи отд. ветку и там продвигай своих умельцев... здесь речь идет совершенно об ином
← →
serge35 (2004-04-14 16:14) [75]Самая быстрая среда разработки - Clarion.
Создаешь словарь, добавляешь в него таблицы, устанавливаешь все связи, нажимаешь кнопочку и он сам формирует меню, формы, ставит на них кнопочки согласно связям, даже отчеты по каждой таблице и по каждому индексу. Вся процедура занимает несколько минут.
Так что все на Clarion!
(Это для тех, кому важна скорость разработки)
← →
Danilka © (2004-04-14 16:17) [76][75] serge35 (14.04.04 16:14)
Зачем? У нас примерно также, только под орокол. :)
Конечно, кроме скорости разработки еще и очень важны ограничения системы, но об этом написано полсотни постов назад, вот-тут:
[32] Anatoly Podgoretsky © (14.04.04 11:51)
:))
← →
kaif © (2004-04-14 17:48) [77]Извиняюсь за длинный постинг, но короче, видимо, не получится...
Как обычно происходит работа на заказ? Имеется успешно работающая на рынке фирмочка, которая что-то хочет за $500. Имеется программист, знающий относительно неплохо Delphi, но не работающий на крутой должности где-нибудь за $1500 в месяц. Так вот фирма (обычно через знакомых или еще как-то) обращается к нему, типа "можешь наприсать такую вот вещь?". Он думает - "а почему бы и нет?". Дельфя у него как правило пиратская, разработка явно тянет на $1000 (пару месяцев работы), но задача интересная, да и опыта коммерческих разработок набраться хочется... Он говорит, бог с вами - давайте сделаю вам это. Начинается обсуждение подробностей (постановка задачи). Потом начинаются переделки и "добавления". Программист начинает нервничать. Одно дело - поднапрячься и за месяц в экстремальном режиме сделать то, что по уму нужно было спокойно делать 2 месяца (минус $500), Другое дело - делать в 3 раза больший объем (уже минус $2500). А кушать что-то тоже хочется... А заказчик все больше "борзеет"...
Зададимся вопросом, а что собственно происходит? Почему это так? Может быть все нормально? Ответ, на самом деле очень прост. Все дело именно в выборе Delphi в качестве средства для такой разработки. Разработка на самом деле стоит намного дороже, чем платит за нее заказчик. В этом вся соль. Он искренне полагает, что если "вот это" стоит $500, то почему бы не добавить еще $200 и получить, например, "вот это"?
Поэтому есть единственный выход - снижение стоимости "эволюционной" разработки. Без применения достаточно мощных CASE-средств это невозможно. Если программист изучит полный набор средств, который позволяет вести "эволюционную" разработку без г#морроя, то он может уже идти смело в фирму, работающую с жирными заказчиками, где ему будут платить $1500. А суммарно все лицензионное ПО для такой работы будет стоить не менее $10,000.
Так что, значит та фирмочка должна остаться вообще без программы? Выходит, что так. Можно, конечно, выучить 1C и пытаться что-то сделать в ней. Но дельфист этим заниматься не хочет, если только голодная смерть еще не на пороге... :)
Я подумал, как сократить время разработки для дельфиста-фаната SQL? Как избежать тех проблем, что возникают в 1С? И нашел определенные решения. Например совершенно другую систему справочников, совершенно другой бухгалтерский баланс и совершенно другой взгляд на именование и доступ к объектам базы данных, чем в 1С. И наконец, другую политику продаж и лицензирования.
В результате удалось выровнять отношения заказчик-программист. Первая конфигурация, которую я писал на заказ в Allegro, через один месяц работы имела версию номер 7 (!!!). При этом я не поссорился с заказчиком, а он "осознал" все, что ему принципиально нужно, быстро, и при этом еще как-то сам интуитивно понял, что такое нормализация, минимализм и требования к уникальности. Такого взаимопонимания раньше с заказчиками у меня так легко не складывалось. Он сам стал стремиться все упростить и выбросить все лишнее.
Это не только мой опыт. Уже несколько человек использовали Allegro для коммерческих заказов. Все отмечают высокую скорость разработки и отсутствие конфликтов с заказчиком в условиях очень плохо формализованных изначально задач.
Вообще четкая схема ТЗ->программа, ИМХО, есть совершенная утопия, если речь, конечно, не идет о заказе более, чем в 10 тыс зеленых.
Я рекомендую попробовать действовать так. Берется Allegro и городятся справочники под клиента. Это можно сделать вместе с ним, у него на фирме за пару часов. Далее городится система счетов баланса. Если заказчик не очень понимает GAAP-баланс. ему можно на пальцах все объяснить или дать программу LEADER Classic http://www.lclassic.ru , чтобы он потыркался в ней. Потом нужно у него выяснить, какой интерфейс решает сразу 90% проблем. Обычно, это интерфейс ввода заказов. Или "сдельной работы". Или еще что-то. Всегда есть такое узкое место на фирме. Обычно даже бывает уже готовый способ как-то это вести в Excel, разработанный добросовестным и талантливым менеджером. Далее уже надо думать. Сделать пару интерфейсов, чтобы заказчик мог поиграться и почувствовать мощь системы. А после этого уже обсуждать условия сотрудничества, сроки и цены. Заказчик должен понимать, что задачу ставит он вместе с Вами. Задача полностью поставлена обычно тогда, когда программа уже внедрена и успешно работает. И только так. На малой фирме, по крайней мере. А этих малых фирм... много. Очень много. Неправда, что им не нужен реальный учет. Это не так. Нужен. И они готовы платить разработчикам. И с ними приятно иметь дело. Там нет бюрократии и ситуаций, когда один платит, другой решения принимает, а третий юзать должен...
← →
DiamondShark © (2004-04-14 17:59) [78]А если фирмочка хочет ещё и "правильную" бухгалтерию?
← →
kaif © (2004-04-14 18:14) [79]2 DiamondShark © (14.04.04 17:59) [78]
Из Allegro можно связаться с 1C, как COM-сервером и экспортировать оттуда документы в "правильную бухгалтерию".
:-)
Однако, как правило, такая задача и не стоит.
Кстати, что касается прозрачности учета. Грядет налоговая реформа. Социальный налог будет снижен с 35% до 26% для зарплат ниже определенной величины, а для более высоких - прогрессивно падать вплоть до 2%. МИНФИН уже подготовил все документы. Я ожидаю резкого уменьшения бутафорского учета, так как именно социальный налог был главной помехой на этом пути. Многие захотят работать вообще вбелую. И тогда ценность бутафорского учета может резко снизиться. Кормушка в налоговой в результате начнет уходить в небытие. И люди начнут задумываться о том, чтобы выбирать более прозрачное и адекватное представление данных. Лучше двустороннего баланса в стиле GAAP пока никто ничего не придумал. Я вынужден быть оптимистом. Или мы имеем реальный учет и управляем бизнесом по-человечески - или вообще ничего не имеем и обманываем сами себя.
← →
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С.
← →
kaif © (2004-04-15 15:24) [109]Ух ты, как много вопросов! И главное - все по существу. Постараюсь ответить по порядку.
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С нуждается в передовых технологиях Аллегро.
← →
Тимохов © (2004-04-15 15:41) [111]
> serge35 (15.04.04 15:37) [110]
Вы в 1с не работаете?
моя имхо говорит, что 1с вообще ни в чем не нуждается - они свое дело уже сделали.
← →
serge35 (2004-04-15 15:52) [112]Не работаю, но за те годы, которые существует 1С просто нельзя не сделать бухгалтерской программы.
← →
LordOfSilence © (2004-04-15 15:58) [113]По-поводу "рыхлой" системы документов и UNION.
Пардон еще раз, сейчас у меня даже Delphi не установлена, не то что Аллегро, поэтому говорю вслепую. Наверняка у тебя в системе есть таблица, где перечислены все заголовочные строки документов. Почему бы общие поля документов не подпихнуть туда?
По-поводу таблиц настроек.
Имеется ли возможность использовать элементы (строки) таких таблиц в качестве атрибутов справочника? Пример: есть справочник сотрудников. Один из атрибутов - пол сотрудника. Есть резон выделить сущность пол в отдельный нередактируемый справочник (таблицу настроек) с предопределенными значениями "муж", "жен" и для политкорректности "транс", дабы у пользователя не было соблазна городить в этом справочнике ахинею. Затем, элементы уже этого справочника подставляются в атрибут "пол" для конкретного сотрудника.
← →
kaif © (2004-04-15 16:02) [114]Что касается двойной записи, аналитики в более, чем 1 поле и так далее, постараюсь разъяснить подробнее.
Принцип двойной записи (в понимании sum(debit) = sum(credit) тесно связан с остальными принципами GAAP, в частности, с принципом балансового уравнения (Средства = Обязательства + Капитал). Поэтому если мы хотим видеть текущее финансовое состояние компании (баланс) и текщую прибыль (в составе этого баланса), мы должны применять принцип двойной записи. Он регулирует отношения собственности. Невозможно, чтобы возник у кого-то долг или куда-то делись деньги просто так, с бухты барахты. Значит, это произошло за счет чего-то другого (средства не берутся с потолка и не исчезают непонятно куда). Поэтому вся часть, связанная со счетами контрагентов, прибылями и учетом средств (баланс) будет всегда опираться на принцип двойной записи и ни на что иное опираться не может.
Одно аналитическое поле является излишество даже в классическом GAAP. Там ничего, кроме счетов вообще нет. Просто аналитическое поле позволяет избавиться от необходимости переставлять счета из левой стороны баланса в правую, и наоборот (когда должник превращается в кредитора и наоборот) автоматизировав этот процесс в целях удобства.
К сожалению, техническая возможность создавать аналитические поля приводит к искушению (как было в 1С) нагрузить финансовый учет несвойственными ему признаками, заодно используя этот вид "сумматора" как сумматор "как таковой" для всевозможных иных целей (множество аналитических полей). Например, для выяснения не только того, где находятся средства, но и кто за них "отвечает", "кто их привез или поставил", "куда их потом со склада нужно будет отправить" и так далее. Все это плохо интерпретируется в рамках модели отношений собственности и приводит к противоречиям, когда мы задаемся вопросом "а что означает остаток на таком-то счете в таком-то разрезе?". В результате часто такие данные страдают неполнотой (не всегда указывалось, кто привез и для кого, так как кое-что привозили для себя или непонятно у кого брали) и так далее. Все это оттого, что финансовый учет не должен был изначально ничего такого содержать вообще. Средства либо лежат на счете склада и принадлежат компании (в виде товара), либо лежат на счете складовщика (он должен деньги, но уже никак не товар), либо на счете поставщика (тот должен деньги, но никак не товар). Они не могут одновременно быть и там и там и там.
Поэтому в конце концов 1С это поняли и ввели регистры для "всяких разных других дел". Однако рудимент нескольких "субконто", так подкупающий юзера, который не знает, что такое баланс, но спешит вводить данные - остался и является большой головной болью при каждом апдейте конфигурации 1С, когда все эти "левые" субконто теряются, а пользователи проклинают все на свете.
Система регистров ресурсов - вещь удобная, но не имеющая прямого отношения к финансовому положению компании. Если компания купила 10 тонн какого-то материала и что-то там из него произвела, потратив на это еще и электроэнергию и нервные клетки, то это ее личное дело. И от того, как именно она склонна считать себестоимость каждой единицы, как она прогнозирует дальнейшее производство и его выгодность/невыгодность, на ее финансовое положение это никак не влияет. Поэтому все это должно быть вне баланса и бухгалтерских проводок. Максиму, что она может отразить в балансе - сам факт того, что материал использован и дальнейшей перепродаже в качестве материала больше не подлежит.
← →
Тимохов © (2004-04-15 16:07) [115]
> kaif © (15.04.04 16:02) [114]
С тем фактом, что в многие факты не должны быть в бух проводках я согласен целиком и полностью.
Но факты то где-то должны быть. Т.е. нельзя же их взять и забыть просто потому, что они противоречят крисоте финансового учата.
Куда вы предлагаете девать всю дополнительную информацию?
← →
Danilka © (2004-04-15 16:14) [116][115] Тимохов © (15.04.04 16:07)
Вообще, как вариант, в проводки можно писать ID документа, по которому они были сделаны. В этом случае, вся экзотика легко вытаскивается из док-та.
Правда, я не знаю как это здесь реализовано, вообще, такое возможно если id уникально для всех документов (что, вобщем-то сделать легко, если для генерации id любого док-та дергать один генератор на всех)
← →
kaif © (2004-04-15 16:14) [117]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]Согласен с Властелином Колец, что нередактируемые справочники нужны как воздух. Кроме пола, есть еще масса выпадающих списков, которые не нуждаются в постоянном обновлении и дополнении.
Просьба к Кайфу - поменьше текста.
← →
LordOfSilence © (2004-04-15 16:22) [119]У меня в ядре нет такой таблицы
А вот тут ты не прав, друг мой. :-)
Уверен, что журнально-подобная таблица должна быть в системе,
где могу быть перечислены АйДишники документов и все эти твои
"поле даты", "поле номера", "поле суммы" и "поле примечаний" и пр.
← →
serge35 (2004-04-15 16:25) [120]> В 1C "План счетов" и "Баланс" - разные вещи. В Allegro это то же самое.
Спасибо за разъяснение, а то я уже 10 лет не могу отличить План счетов от Баланса. Ооочень свежее замечание!
← →
serge35 (2004-04-15 16:29) [121]Можно создать базу данных всего из 3-х таблиц и с помощью этих таблиц проводить документы. Вопрос только в том, с какой скоростью это будет работать, т.к. будет большое количество обращений к одной таблице.
← →
Тимохов © (2004-04-15 16:34) [122]
> serge35 (15.04.04 16:29) [121]
у нас кол-во таблиц равно 20.
классов больше 300.
медленно, конечно, но зато гибко.
при том некоторые запросы было бы просто нереально написать в стандартной реляционке.
периодически начинается борьба за ускорение - иногда успешно :)))
← →
serge35 (2004-04-15 16:38) [123]Есть система Фигаро - в ней 150 таблиц, но этого оказалось вполне достаточно чтобы разруливать производственные процессы на крупных предприятиях металлургической промышленности!
Баланс, зарплата, кадры, закупки, продажи, договора - это само собой разумеется.
← →
Тимохов © (2004-04-15 16:41) [124]
> serge35 (15.04.04 16:38) [123]
имхо это ни о чем не говорит.
поясню.
что такое "крупно" - объем данных или количество пользователей?
вообще говоря определение данного термина важно, т.к.
при хранее всего и вся в несколькоих таблицах отчеты даже при больших объемах работают вполне пристойно, а вот при большом количестве пользователей часто натыкаешься на deadlock"и.
← →
Digitman © (2004-04-15 16:45) [125]офф-топик : эк я невзначай задел народ сей темой.... вовсе, кажись, не Аллегро"вской. а в принципе ....
однако, приятно ....
...осознавать, что не один ты паришься в этой "бане" ...
← →
Digitman © (2004-04-15 16:52) [126]бьюсь об заклад - чуть ли не кажный 3-й али 4-й программер из числа ув.посетителей нашего родного ресурса есть озабоченный тем самым, о чем мы то бишь тут ...
← →
DiamondShark © (2004-04-15 16:54) [127]
> бьюсь об заклад - чуть ли не кажный 3-й али 4-й программер
> из числа ув.посетителей нашего родного ресурса есть озабоченный
> тем самым, о чем мы то бишь тут ...
Или был когда-то озабочен...
Или собирается озаботиться...
;-)
← →
Тимохов © (2004-04-15 17:03) [128]
> Digitman © (15.04.04 16:52) [126]
Не надо быть Шерлок Хомсом, чтобы это понять. :)))
Поясню.
Вы же не удивитесь придя на форум по Direct X тому, что большинство хочет сделать красивые 3д игры.
Вот и тут - на форуме по продукту, который позиционируется как быстрое средство разработки бизнес решений сложно имхо удивлятся тому, что большинство (ну или немаленькая часть) пишет финансовые системы...
← →
Polevi © (2004-04-15 17:03) [129]>Digitman © (15.04.04 16:52) [126]
мне нравица :)
← →
LordOfSilence © (2004-04-15 17:10) [130]2 Digitman
Это еще MsGuns"а нет... Он бы задал жару :-)
← →
kaif © (2004-04-15 17:11) [131]Тимохов © (15.04.04 16:07) [115]
> kaif © (15.04.04 16:02) [114]
С тем фактом, что в многие факты не должны быть в бух проводках я согласен целиком и полностью.
Но факты то где-то должны быть. Т.е. нельзя же их взять и забыть просто потому, что они противоречят крисоте финансового учата.
Куда вы предлагаете девать всю дополнительную информацию?
В Allegro можно создавать любые типы документов. Только какие-то из них проводятся.
Danilka © (15.04.04 16:14) [116]
[115] Тимохов © (15.04.04 16:07)
Вообще, как вариант, в проводки можно писать ID документа, по которому они были сделаны. В этом случае, вся экзотика легко вытаскивается из док-та.
Именно так и сделано в Allegro. Все ID документов порождаются генератором DOC_ID_GEN. Все ID справочных элементов порождаются генератором OBJECT_ID_GEN. Формат таблицы проводок содержит эти два поля./*Таблица проводок*/
CREATE TABLE ACC_TURN (
OP_DATE TDATE,
ACC_ID TACCOUNT,
LAYER_ID TIDENTITY,
OBJECT_ID TIDENTITY,
TEMPLATE_ID TIDENTITY,
DOC_ID TIDENTITY,
IS_CREDIT TBOOLEAN,
DEBIT TTURNOVER,
CREDIT TTURNOVER,
QUANTITY_DEBIT TQUANTITY_TURNOVER,
QUANTITY_CREDIT TQUANTITY_TURNOVER,
CONSTRAINT PK_ACC_TURN PRIMARY KEY (OP_DATE, ACC_ID,
LAYER_ID, OBJECT_ID, TEMPLATE_ID, DOC_ID, IS_CREDIT)
);
serge35 (15.04.04 16:25) [120]
> В 1C "План счетов" и "Баланс" - разные вещи. В Allegro это то же самое.
Спасибо за разъяснение, а то я уже 10 лет не могу отличить План счетов от Баланса. Ооочень свежее замечание!
В этом замечании есть смысл.
Когда бухгалтер в Allegro добавляет счет в баланс, он осознанно принимает решение о том, куда его в балансе поместить.
Когда бухгалтер добавляет счет в 1С, он об этом может не задумываться вообще. Для добавления этого счета в баланс нужно звать программиста, который добавит его в отчет, называемый "балансом". Поэтому бухгалтер вместо того, чтобы добавить счет, добавляет "субконто" в какой-нибудь существующий счет. Этот подход ведет к кривому учету и неправильному балансу.
← →
Digitman © (2004-04-15 17:20) [132]
> Polevi © (15.04.04 17:03) [129]
знаешь ли, мне тоже ... но тонкости хотелось бы знать ... прежде чем что-то ...
← →
serge35 (2004-04-15 17:21) [133]Крупные предприятия - предприятия на которых работет не менее 2000 человек.
Пользователей порядка 200.
По количеству транзакций точно сказать не могу.
Но если взять к примеру один цех и расписать все движение сырья, материалов, полуфабрикатов, получается целая кипа документов, большинство из которых создеатся автоматически. Эдакий генератор документов.
Кайф раздражает тем, что все должны решать свои задачи так, как он считает нужным.
У меня тоже были мысли создать систему, в которую можно было бы легко добавлять документы, но потом я понял, что универсальную систему, отвечающую всем требования написать невозможно. Надо к каждому заказчику подходить индивидуально.
← →
kaif © (2004-04-15 17:31) [134]1. Почему я опубликовал рекламу на этом форуме? Потому что я хотел создать дельфийский ответ 1С. И рассчитываю на то, что здесь меня поймут и поддержат разработчики - сторонники реляционных подходов.
2. Как я вижу развитие Allegro? Я приглашаю дельфистов создать стандартные конфигурации Allegro, заточенные под разные сферы бизнеса. Оболочка сделана так, чтобы именно дельфисту было привычно и приятно с ней работать, если есть желание попробовать. Пожелания создателей стандартных конфигураций по отношению к оболочке и ядру будут учитываться. Продажи конфигураций принесут им доходы. Я намерен создать что-то вроде клуба разработчиков. Столько было разговоров о "совместном проекте". Считайте gaapinvest - форматом такого проекта. Те, кого интересует вопрос об "экспертизе" стандартных конфигураций - эта экспертиза пока лично мной и обсуждаться на этом форуме (если модераторы не возражают), а в дальнейшем - самим клубом (когда появятся первые такие разработки).
← →
Тимохов © (2004-04-15 17:36) [135]
> kaif © (15.04.04 17:31) [134]
Вы один работаете?
Вопрос вызван тем, что мы также делаем что-то похожее, но для своих заказчиков. Т.е. задача была написать просто систему, написали в итоге платформу. Но как всегда не доделали. Меня смущает вообще теоретическая возможность одному поддерживать и развивать достойную платформу.
← →
kaif © (2004-04-15 17:37) [136]serge35 (15.04.04 17:21) [133]
Кайф раздражает тем, что все должны решать свои задачи так, как он считает нужным.
У меня тоже были мысли создать систему, в которую можно было бы легко добавлять документы, но потом я понял, что универсальную систему, отвечающую всем требования написать невозможно. Надо к каждому заказчику подходить индивидуально.
У меня такое впечатление, что Вы недостаточно познакомились с Allegro. Она так и написана, как Вы говорите. В этой системе нет никакой возможности "просто добавлять документы". Каждая конфигурация пишется под заказчика и в ней создаются именно те типы документов, которые нужны заказчику. Изначально в Allegro вообще нет никаких документов, кроме ручных проводок. Я исходил именно из того, что написать
универсальную систему, отвечающую всем требования написать невозможно
Но возможно написать систему, в которой конфигурирование не будет изначально противоречить реляционным подходам. Если решить ряд проблем. Мне кажется, что главные из них мне удалось решить.
← →
serge35 (2004-04-15 17:43) [137]Я почему то всегда считал, что План счетов един и он весь расписан в руководстве по бухучету.
За предприятием остается право добавлять субсчета по аналитике, принятой на предприятии.
Поэтому счет, добавляемый бухгалтером является субсчетом счета плана счетов.
Т.к. место каждого счета в балансе известно, то соответственно известно и место в балансе всех субсчетов данного счета.
Поэтому, для того, чтобы новый субсчет попал в баланс никаких изменений в балансе не требуется.
Насколько я знаю, каждый счет и субсчет в 1С имеет массу реквизитов и может входить в разные группы для формирования не только баланса, но и налоговой отчетности, для расчета различных соц. отчислений и т.д.
Баланс - строго расписанный отчет. И никакой бухгалтер не может принимать "решение о том, куда его в балансе поместить".
Для каждого счета в балансе есть строго определенное место.
Обычно бухгалтеру достаточно отчета "Сводная оборотно-сальдовая ведомость" для того, чтобы составить баланс в бланке.
← →
serge35 (2004-04-15 17:47) [138]>Мне кажется, что главные из них мне удалось решить.
Какие же проблемы решены в Алегро?
← →
Polevi © (2004-04-15 17:50) [139]>План счетов един и он весь расписан в руководстве по бухучету
да нафиг он не нужен, он в нашей стране расписан, а GAAP если я понял дает возмодность самому строить дерево счетов
← →
kaif © (2004-04-15 17:52) [140]Тимохов © (15.04.04 17:36) [135]
> kaif © (15.04.04 17:31) [134]
Вы один работаете?
К сожалению, код пишу я один. Не так легко найти людей, которые согласились бы вкладывать столько энергии в проект, не имея никаких гарантий оплаты. Но у меня есть единомышленники и деловые партнеры. Философия Allegro обсуждалась гораздо дольше и доскональнее, чем писался ее код. И уже имеется несколько разработчиков, конфигурирующих в Allegro. И несколько выполненных заказов. Мы сами зарабатывали деньги для Allegro (нужно было покупать компоненты и так далее). Сейчас зарабатываем, уже используя Allegro. Таким образом проект не был изначально "привязан" к какому-то заказчику и сохранял свою финансовую независимость. Никаких "спонсоров" или "инвесторов" у него нет. Права на систему Allegro принадлежат компании DAVSAR. Это наша компания (моя и моего друга в Москве).
Я стараюсь не добавлять в систему ничего, что можно "наконфигурить руками", если это не дает значительного выигрыша именно для разработчика. Это система для разработчиков, а не для пользователей. Она позволяет разработчику эффективно решить проблемы пользователя.
← →
Тимохов © (2004-04-15 18:00) [141]
> Polevi © (15.04.04 17:50) [139]
не совсем - там есть несколько (очень немного) балансовых счетов, которых надо придерживаться. Типа:
основные средства
оборотные актвы
обязательства
основной капитал
(точно не помню, но что-то типа этого)
Kaif. Убедили, обязательно поизучаю - очень уж заманчивые перспективы: "не для пользователей, а для разработчиков".
← →
kaif © (2004-04-15 18:02) [142]serge35 (15.04.04 17:43) [137]
Я почему то всегда считал, что План счетов един и он весь расписан в руководстве по бухучету.
Это так только в российском регламентированном учете. Он совершенно неприемлем для реального бизнеса. И он совершенно неприемлем для отчетности в международных стандартах. И его уже отменяют для целых отраслей в России. У этого учета нет никакого будущего. Этот учет приводит к низкому уровню компетентности бухгалтеров, совершенно неприемлем для инвесторов и удовлетворяет очень ограниченные информационные потребности - в основном налоговых и контролирующих органов. Во всех развитых странах мира (от США до Сингапура) используется GAAP. В GAAP нет никакой регламентации счетов. Есть только общие принципы и общие разделы. В GAAP совершенно отсутствуют всевозможнве активно-пассивные счета, не имеющие никакого экономического смысла. Бухгалтер General Electric, составляет баланс, содержащий тысячи счетов в течение дня (раньше он это делал вручную) и кладет его на стол директору. Наш бухгалтер 3 месяца корпеет над балансом из пары десятков счетов и сдает его "контролирующим органам". Это результат практики регламентированного и бессознательного учета.
← →
serge35 (2004-04-15 18:03) [143]Я бы не стал покупать компоненты.
Но купил бы хорошее ТЗ.
← →
serge35 (2004-04-15 18:10) [144]>Он совершенно неприемлем для реального бизнеса
Это только на первый взгляд. Те, кто хорошо знают систему учета запросто сдают отчетность и скрывают свои реальные доходы.
Так может относится к бухучету лишь человек, знающий его весьма поверхностно.
Мой совет - не торопитесь с написанием системы "облегчающей" жизнь программисту, а займитесь изучением той предметной области, для которой пишется ПО, чтобы "облегчение" не стало "медвежьей услугой".
← →
kaif © (2004-04-15 18:30) [145]serge35 (15.04.04 17:47) [138]
Какие же проблемы решены в Алегро?
Это очень длинный список и лучше, если я опубликую специальную такую страницу на сайте. Сейчас, возможно, я что-то упущу существенное...
- решена проблема совмещения линейных справочников с разнообразными атрибутами (классов) с реляционным подходом.
- решена проблема поддержки быстрого (100тыс проводок/сек) баланса в условиях непредсказуемого и постоянно развивающегося дерева счетов с аналитикой и развернутыми сальдо (на уровне ядра системы). Баланс (все уровни дерева) собирается одним SQL-запросом.
- проведение документа осуществляет сервер, а не клиент, причем в классической 2-х звенной модели клиент-сервер. КомандаINSERT INTO "таблица проводок" SELECT FROM "процедура шаблона виртуальной операции" GROUP BY "ключевые поля".
Текст хранимой процедуры шаблона генерируется самой системой Allegro при настройке шаблона. Процедура обращается к таблицам документа и извлекает оттуда данные, выдавая результат в формате журнала. В результате группировки перед вставкой и GAAP-формату таблицы (вертикальное расположение записей) число вставляемых записей уменьшается до минимума. Это позволяет достичь теоретического предела максимума быстродействия при сборке баланса.
- при редактировании документа задним числом не нужно перепроводить все более поздние документы, так как проводки не допускают использования оборотов. Для этой цели существует иной (двухтактный) идеологический механизм.
- "конфигуратор" и приложение соединены "в одном флаконе", что значительно ускоряет работу разработчика.
Я боюсь, что я и так злоупотребляю размером постинга, поэтому вынужден этим ограничиться. О многих вещах можно почитать на сайте (об Allegro). Но видимо, следует сделать еще отдельную страницу...
← →
kaif © (2004-04-15 18:40) [146]serge35 (15.04.04 18:10) [144]
Мой совет - не торопитесь с написанием системы "облегчающей" жизнь программисту, а займитесь изучением той предметной области, для которой пишется ПО, чтобы "облегчение" не стало "медвежьей услугой".
Судя по Вашим высказываниям о бухгалтерском учете, Вы гораздо хуже меня разбираетесь в этом вопросе.
Я не тороплюсь. Я уже написал систему. И ее уже используют те, кому нужно иметь представление о реальном положении дел в своих компаниях. Кстати, эта система, повторюсь, совместима с существующим российским учетом. Но, в отличие от 1С, она совместима с любой системой учета, если этот учет бухгалтерский. Кроме французской, пожалуй.
А совместимой с российским учетом Allegro стало после многих изменений, которые МИНФИН уже внес в существующее законодательство. Раньше они не были так очевидно совместимы.
← →
kaif © (2004-04-15 19:45) [147]Разберем простой пример. Он покажет, кто разбирается в бухучете, а кто - нет.
Как-то на дне рождения моего друга, я встретил опытную бухгалтершу, которая гордилась тем, что "сегодня нашла деньги". Я у нее спросил, как можно "найти деньги"? Она ответила, что списала кредиторскую задолженность в прибыль. Я спросил "то есть увеличили налогооблагаемую базу? И налоги заплатили?". Она сказала "Да. Но зато появились деньги в прибыли, в счет которых я произвела ряд расходов, чем обрадовала директора, который не мог поверить, что нашлись какие-то деньги". Речь шла о сумме порядка $25,000. Я спросил, а что за задолженность такая кредиторская? Она ответила, что это инвестиция, которую они получили от иностранного партнера 3 года назад. Я спросил, а предупредила ли она иностранного партнера о том, что собирается сделать такую бухгалтерскую проводку? Она удивленно уставилась на меня.
Я сказал тетке, что она совершила грубую ошибку, граничащую с воровством денег. Она не поняла. Потом мы стали обсуждать еще кое-что и сильно поссорились.
Вопрос:
В чем ошибка, в чем проблема и как следовало действовать?
← →
kaif © (2004-04-15 20:06) [148]serge35 (15.04.04 18:10) [144]
Те, кто хорошо знают систему учета запросто сдают отчетность и скрывают свои реальные доходы.
Это не сложно. Сложно другое: к сожалению, потом они не могут объяснить друг другу, каковы были эти реальные доходы. И возникают трупы. Бухучет GAAP делает бизнес прозрачным для партнеров. "Управленический учет" (как его называют в России) развивается именно потому, что дальше так работать невозможно. Наш управленческий решает те задачи, которые во всем мире решает учет бухгалтерский. А те задачи, которые решает их "управленческий" нам и не снились. Так как сначала нужно научиться элементарно вести дела и правильно рассчитывать прибыль. И знать, как получить ряд показателей (коэффициентов), характеризующих бизнес. Без нормальной отчетности не может заработать рынок капитала. Это эквивалентно отсутствию капитализма вообще. Согласно указу Ельцина, полный переход на международный бухучет должен был быть совершен до 1 марта 2000 г. согласно обещаниям Касьянова - до января этого года. Спрашивается, где он? Ответ - всегда один. "У нас нет ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ, позволяющего вести учет в международных стандартах".
Теперь это программное обеспечение есть.
А мне говорят, что это "медвежья услуга".
← →
Сергей Суровцев © (2004-04-16 00:10) [149]>kaif © (15.04.04 20:06) [148]
>Наш управленческий решает те задачи, которые во всем мире
>решает учет бухгалтерский. А те задачи, которые решает их
>"управленческий" нам и не снились. Так как сначала нужно
>научиться элементарно вести дела и правильно рассчитывать
>прибыль. И знать, как получить ряд показателей (коэффициентов),
>характеризующих бизнес.
Ашот, ну не нужно так категорично. Советская система бух.учета
вполне стройна и логична. Некоторые ее пункты действительно
были слишком сильно привязаны к текущему законодательству,
но именно как система она вполне достойна. И в этом смысле
GAAP от нее ничем принципиально не отличается. Другое дело,
что менеджмент даже сегодня в массе своей не в состоянии
читать финансовые документы как есть и предпочитает различные
выборки и выжимки. Действительно баланс а"ля Минфин не дает
нормальной картины состояния предприятия. Но получить ее
из тех же исходных данных довольно просто. Это же не
принципиально. А насчет "правильно рассчитывать прибыль", так
на любом нормальном предприятии это делать умеют. Причем
и в реальной версии, и версии по Минфину. Другое дело, что
эти реальные показатели не имеют статуса официальной
отчетности. Но это уже вопрос не к базовой системе бух.учета,
а к ее конкредной интерпритации.
Говорю не по наслышке, ибо сам "асучивал" несколько сотен
предприятий, в том числе и очень не маленьких. Реальную
прибыль и затраты они всегда собрать умеют. Если, правда,
у них гл.бухгалтер с нормальной головой, а это все же редкость.
>serge35 (15.04.04 15:37) [110]
>Я не думаю, что 1С нуждается в передовых технологиях Аллегро
Она вообще не нуждается в передовых технологиях. Все ее
технологии выходят с запозданием года на 3-4. Просто не все
могут громко врать "купите наш продукт и проблем у вас больше
не будет", в то время, как с такой покупкой проблемы как раз
только и начинаются. И огромные.
>LordOfSilence © (15.04.04 11:25) [89]
>4. Есть ли возможность создавать справочники, доступные для
>изменения только программистом?
Такой справочник называется просто отдельной таблицей, из
которой можно тягать данные. В простейшем, естественно,
варианте, пока таковое не предусмотрено самой системой.
>Polevi © (15.04.04 10:25) [87]
>меня смущает возможность привязки к счету только одного
>уровня аналитики у 1С 6 версии было 3 уровня
Никогда не мог понять реальной пользы от этого. Поясните,
пожалуйста на примере, где это ДЕЙСВИТЕЛЬНО необходимо?
>Тимохов © (15.04.04 16:07) [115]
>С тем фактом, что в многие факты не должны быть в бух
>проводках я согласен целиком и полностью.
>Но факты то где-то должны быть. Т.е. нельзя же их взять и
>забыть просто потому, что они противоречят крисоте
>финансового учата.
>Куда вы предлагаете девать всю дополнительную информацию?
Больной вопрос современности. При хорошо поставленой системе
бух.учета, в том числе и по документам (в совокупности,
естественно с мат. учетом) бухгалтерия остается единственным
работающим отделом. Остальных экономические блок просто
тягают выборки из их информации, а то и просто получают
готовые отчеты. :))
>Danilka © (15.04.04 16:14) [116]
>Вообще, как вариант, в проводки можно писать ID документа,
>по которому они были сделаны. В этом случае, вся экзотика
>легко вытаскивается из док-та.
А что, это где-то делается иначе? :))
>kaif © (15.04.04 19:45) [147]
>Разберем простой пример.
Похоже Ваша дама из примера относится к "совковым" бухгалтерам
вроде банковских работников, искренне считающих, что это
именно они выдают людям деньги а не сами временно пользуются
деньгами этих людей.
Дама нагрела собственного инвестора просто присвоив себе его
деньги, которые предприятие получило в виде инвестиций.
Технически предприятие взяло в долг и если бы долг этот ему
спиисали, то это можно было бы считать прибылью. А так оно
самостийно "простило" инвестору свой долг перед ним.
Изящно, хотя и незаконно. :))
>Спрашивается, где он? Ответ - всегда один. "У нас нет
>ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ, позволяющего вести учет в
>международных стандартах".
>Теперь это программное обеспечение есть.
>А мне говорят, что это "медвежья услуга".
Я завидую Вашей скромности! :)))
Реально с приходом международных стандартов проблемы только
начнутся ибо рынок откроется для монстров, для которых
этот стандарт родной. Вы же не думаете, что весь Запад
считает на счетах, правда? Так что проблема в чем угодно,
но только не в отсутствии программоного обеспечения. Ну а
дальше будет видно.
← →
kaif © (2004-04-16 01:45) [150]2 Сергей Суровцев © (16.04.04 00:10) [149]
Спасибо за взвешенное и объективное мнение. Согласен почти со всем, кроме того, что между GAAP и нашим регламентированным учетом можно поставить знак равенства. Дело в том, что существует определенная связь между уровнем грамотности бухгалтеров, применяемой моделью бухгалтерского учета и развитостью биржевых и инвестиционных инструментов. Различают 3 модели: англо-американо-голладская или GAAP (государство не вмешивается в учет), континентальная (Франция, Германия - государство сильно вмешивается) и латино-американская (государство вмешивается во все подряд). Дело в том, что информационные потребности инвесторов и государственных (статистических) органов различаются между собой.
Приведу простой пример. Возьмем такие доисторические счета (я даже не знаю, существуют ли они в последней редакции или нет), как "Деньги в пути" и "Товары в пути". С точки зрения налоговой инспекции, которую волнует только уплата НДС - существование таких счетов вполне оправдано. А вот с точки зрения инвестора - нет. Ему важно знать, чьи это товары и чьи это деньги. Поэтому при переходе с российской системы на GAAP остатки на всех таких счетах инвентаризуются и расследуется, о чем вообще шла речь. В конце концов все эти цифры должны либо превратиться в собственные материальные активы, либо в дебиторские задолженности каких-то контрагентов.
И так все. Например, все активно-пассивные счета "расчетов" тоже должны быть закрыты при таком переходе, так как никакой экономической сущности такие активно-пассивные счета вообще не выражают.
Сам дух советского бухучета не имеет ничего общего с учетом капитала, а лишь с учетом средств: откуда куда что перемещалось и куда делось. С деньгами в российском учете обращаются, как с вещами. Не случайно тетенька кинула инвесторов. Она и не подозревала о разнице между кредитом и инвестицией. А какая ей разница, если оба счета могут корреспондировать с расчетным счетом и обе проводки "правильные" с точки зрения МИНФИНА? Да еще и по дороге зачем-то вклинивается такой экономически непрозрачный технический счет, как "расчеты с учредителями"...
Российский бухучет не просто так остается прежним. На то существует огромная масса не очень приглядных причин. Например, в 1999 г, согласно МИНФИНУ, акционирование предприятия нужно было проводить следующим образом:
1. Печатаем акции и учитываем их как "ценные бумаги" (!)
2. Раздаем акции в долг и записываем задолженность (!)
3. Погашаем задолженность по мере того, как акционеры внесут деньги за приобретенные таким способом акции. :)))))
---------------------------------------------
Это совершенно потрясающая схема! Каждый из этих шагов представляет собой по сути узаконенную кражу предприятия.
Для сравнения, например, в США:
1. Собственные акции предприятия активом считаться не могут, так как они вообще ничего пока не стоят. Акции учитываются после продажи (д-т, Денежные средства, К-т "Акции в обращении")
2. Встречным удовлетворением по акции не может быть ни долг, ни простой вексель, ни будущая работа. Почему это так? Да потому что акция не вещь, которую можно купить в кредит, а право на управление и участие в прибыли. И оно не может передаваться кому-то в долг. Без того, чтобы этот инвестор не предоставил реальные ресурсы взамен на каждую акцию.
Моного людей задается вопросом, как удалось каким-то людям (например бывшим директорам) завладеть контрольными пакетами акций заводов или отраслей, которые стоят миллионы долларов? А вот так и удалось! Достаточно, чтобы бухгалтер сделал проводки в точном соответствии с правилами, рекомендованными МИНФИНОМ. Эти акции могли быть попросту переданы в долг. А потом долг "погашен" из дивидендов. Это из серии "найдите 2 отличия от того, как устроен GAAP" :).
Точно так же иностранные инвесторы, вкладывали деньги, ничего не понимая в российском бухучете и многие наивно надеялись, что под инвестицией здесь понимают именно то, что следует под этим понимать. Так как за рубежом бухучет это - не просто "способ считать". Бухгалтерия во всем мире - язык бизнеса. И если деньги или оборудование используются как инвестиция, то никому в страшном сне не приснится, что здесь бухгалтер проведет эту сумму как кредит. И что существует законодательство, позволяющее списать такой кредит в прибыль и да еще и заплатить с нее налоги.
Так что дело не в том, стройная в России бухгалтерия или нет. Вопрос здесь гораздо существеннее поставлен. Устроена ли российская бухгалтерия так, чтобы возможны были нормальные экономические и партнерские отношения или нет? Или здесь всегда возможен захват собственности, "дочерние и независимые фирмы", на которые можно вполне законно перевести активы, где должники могут не платить, а по обязательствам отвечают не правом собственнности владельцев на бизнес, а лишь оставшимися активами в самом бизнесе.
А в остальном, если говорить о чистой технике - Вы правы.
Но дело не только в технике. Дело еще и в самом мышлении. Баланс в стиле LEADER Classic или Allegro изменяет стиль мышления бухгалтера. Он начинает понимать, что фирма - это не набор средств, а сложный клубок экономических отношений. Остатки на счетах это не просто цифры. Это различные права собственности. И обращаться с ними нужно соответствующим образом.
← →
kaif © (2004-04-16 02:19) [151]Я очень благодарен всем, кто задает вопросы и высказывает конкретные предложения. Ряд вещей я попросту упустил (например, режим ReadOnly справочников). Поэтому я подумал, может сделать страницу на сайте gaapinvest, где я буду публиковть основные предложения и критические замечания по самой системе с ответами на них. Многое из этой ветки вошло бы туда. Кстати, как Вам сайт? Его делал мой товарищ. Тот же, что делал www.lclassic.ru
← →
Danilka © (2004-04-16 08:34) [152][137] serge35 (15.04.04 17:43)
> Я почему то всегда считал, что План счетов един и он весь
> расписан в руководстве по бухучету.
Для справки: на ВАЗе в плане счетов несколько сот тысяч счетов (по крайней мере год назад так было). :)
> За предприятием остается право добавлять субсчета по аналитике,
> принятой на предприятии.
> Поэтому счет, добавляемый бухгалтером является субсчетом
> счета плана счетов.
Ну, в идеале так, и то не всегда. Если надо - добавляй счета на здоровье, только согласовывай с Минфином. А вообще, далеко не все делят счета на счет/субсчет. И даже при делении, субсчета одного счета могут работать очень по-разному. Даже в минфиновсом плане счетов, надеюсь не надо их здесь расписывать? :))
Да и вообще, что такое счет, а что такое субсчет? Это просто уровень аналитики, который может быть двухзначным (счет в обычном понимании) каким-нибудь трех-четырех (и даже девяти) значным, а также однозначным (например, все счета 5% - это по-сути деньги).
> Т.к. место каждого счета в балансе известно,
Да ну, серьезно? :))
Честно говоря, лениво разбирать бланк баланса, но на самом деле, по одной и той-же оборотке разные бухгалтера могут по-разному заполнить баланс. Тот что в налоговую сдается. И никаких проблем или ошибок при проверке выявлено не будет.
> Баланс - строго расписанный отчет.ъ
Но он не один. Этот только в России он один. Тем не менее, крупняки сейчас вынуждены делать еще и параллельно баланс по МСФО - иначе далеко не всегда возможна нормальная работа с зарубежными партнерами.
А по МСФО нет установленного бланка баланса. Бланков расшифровок и т.д. Скачай отчетность разных предприятий и посмотри: у одних она будет на 20-и листах, у других на 200-х.
А вообще, дружище, что мне в тебе офигенно раздражает, это то, что ты пытаешься рассуждать о системе, которую сам не видел, и при этом навешиваешь на нее какие-то выдуманные ярлыки.
[149] Сергей Суровцев © (16.04.04 00:10)
>А что, это где-то делается иначе? :))
Угу. Уже посте того как написал понял что по-другому сделать будет тяжело - иначе не получится вычищать проводки при отмене проведения документа.
← →
Danilka © (2004-04-16 08:40) [153]Кстати, кто-нибудь задумывался над выдуманным 1с словом "субконто"?
count - счет, subcount - субсчет, так что субконто - субсчет с каким-то итальянским акцентом. :))
Почему они не использовали стандарт: "аналитика", непонятно, но теперь субконто стало стандартным.
← →
Danilka © (2004-04-16 08:47) [154][148] kaif © (15.04.04 20:06)
> Ответ - всегда один. "У нас нет ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ,
> позволяющего вести учет в международных стандартах".
На самом деле не только есть, но и очень много предприятий ведут либо параллельно учет, либо делают трансформацию из российской отчетности. Но по-второму варианту, во-первых все равно получается лажа и подгон циферок, во-вторых, без дополнительных расшифровок не обойтись.
← →
Думкин © (2004-04-16 08:57) [155]
> Danilka © (16.04.04 08:34) [152]
> Угу. Уже посте того как написал понял что по-другому сделать
> будет тяжело - иначе не получится вычищать проводки при
> отмене проведения документа.
Речь об этом: http://axapta.mazzy.ru/articles/reposting/ ?
Или как?
← →
Danilka © (2004-04-16 09:24) [156][155] Думкин © (16.04.04 08:57)
Интересная статья, спасибо, прочитал.
Правда, не совсем согласен: в реальной жизни тоже, подписал какую-нибудь бумажку, печать поставил, а потом оказалось что там есть какие-то ошибки, рвешь ее нафиг и печатаешь заново.
Кроме того, даже в 1с-ке пишется лог, кто чего когда изменил, в каталоге SYSLOG.
А вообще, надо все обдумать, так сходу не получится сказать, что более верно, тем-более, мозги пока повернуты в одну сторону, туда, как привычнее.
← →
Polevi © (2004-04-16 09:35) [157]по поводу перепроведения
мне кажется без него не обойтись в реальной жизни
допустим мы перемещаем со склада сырье в пр-во - по той цене сколько сырье стоит с учетом инвойса партии и доп. затрат на таможню и транспорт
из этого сырья сварили ГП, - его стоимость сложилась из стоимости сырья и доп. затрат на пр-во
и после этого выяснилось что на используемое сырье легли еще какието затраты, в итоге получается что мы переместили его в пр-во по неправильной цене. что делать будем ?
← →
Polevi © (2004-04-16 10:06) [158]>Сергей Суровцев © (16.04.04 00:10) [149]
если честно, чтото в голову больше одного уровня не лезет :)
← →
serge35 (2004-04-16 10:32) [159]Счетов в бухучете от 01 до 99, плюс забалансные счета, начинающиеся с 00 и все.
А сотни тысяч счетов на ВАЗе - это субсчета.
Не надо путать теплое с мягким.
← →
serge35 (2004-04-16 10:38) [160]Я еще 2 года назад написал генератор текста хранимых процедур, но не кричу об этом на весь Инет. Потому, что это всего лишь повседневная, рутинная работа программиста.
← →
Думкин © (2004-04-16 10:40) [161]> serge35 (16.04.04 10:38) [160]
И...? А в чем проблема, не нравится обсуждать это - никто за рукав не тянет.
Есть сабж - причем тут крики?
← →
Тимохов © (2004-04-16 10:57) [162]Странное какое-то обсуждение получается.
Начали про аллегро, перешли на российский бухучет.
Связи не вижу.
Больше всего согласен с "Сергей Суровцев © (16.04.04 00:10) [149]" - реальные доходы люди считать умеют, тоже знаю не по наслышке. Никакой gaap им нафиг не нужен - нужно правильно заплатить налоги.
> serge35 (16.04.04 10:38) [160]
У меня тоже есть генератор, тоже молчу, пока.
← →
Danilka © (2004-04-16 11:01) [163][159] serge35 (16.04.04 10:32)
Да ну? Может это только твое личное мнение, что счет может быть только двухзначным а все остальное - субсчета? Если нет, то обоснуй.
Приведи пример, когда Минфин кому-то запретил завести не двухзначный счет в плане счетов. :)
И еще, попробуй привести определение для счета и для субсчета, такое, чтобы любой из минфиновских счетов можно было отнести только к счетам, а любой из субсчетов - к субсчетам если все их выписать слитно: СчетСубсчет, например: 68.30 - 6830. Некоторые субсчета одного счета отличаются ничуть не меньше чем некоторые счета между собой.
Я даже не говорю про банковский план счетов, который вообще совсем другой.
← →
Danilka © (2004-04-16 11:12) [164]Точнее, хотел сказать:
Некоторые субсчета одного счета по логике работы с ними отличаются ничуть не меньше чем некоторые счета между собой.
:))
И вообще, понятие субсчета устарело и ненужно. :))
Субсчет - это аналитика по счету. И пришло это из тех древних времен, когда бухши считали на счетах или на куркуляторах. А сейчас есть "субконто" для этого.
А счета отличаются именно назначением и работой с ними.
← →
serge35 (2004-04-16 11:32) [165]> Субсчет - это аналитика по счету
С этим я совершенно согласен.
> когда бухши считали на счетах или на куркуляторах
А как переводится слово компьтер?
> А сейчас есть "субконто" для этого.
Несколько постов назад это слово было раскритиковано в пух и прах.
← →
serge35 (2004-04-16 11:35) [166]У меня еще прога, позволяющая создавать рабочие формы без программирования и без компиляции. Работает, правда только а Ораклом.
На ней тоже можно создавать любые конфигурации.
← →
DiamondShark © (2004-04-16 12:03) [167]
> Polevi © (16.04.04 09:35) [157]
> по поводу перепроведения
> мне кажется без него не обойтись в реальной жизни
> допустим мы перемещаем со склада сырье в пр-во - по той
> цене сколько сырье стоит с учетом инвойса партии и доп.
> затрат на таможню и транспорт
> из этого сырья сварили ГП, - его стоимость сложилась из
> стоимости сырья и доп. затрат на пр-во
> и после этого выяснилось что на используемое сырье легли
> еще какието затраты, в итоге получается что мы переместили
> его в пр-во по неправильной цене. что делать будем ?
Ничего не делать.
Отдельным документом оформлять.
← →
Polevi © (2004-04-16 12:25) [168]>DiamondShark © (16.04.04 12:03) [167]
и как сумму этого отдельного документа разнести на себестоимость ГП ?
← →
DiamondShark © (2004-04-16 12:31) [169]
> и как сумму этого отдельного документа разнести на себестоимость
> ГП ?
Примерно так же, как если б после изготовления ГП вруг бы выяснилось, что для того, чтобы вынести её из цеха надо нанять ещё N+k грузчиков.
Не вижу проблемы.
← →
Polevi © (2004-04-16 12:42) [170]то есть вы предлагаете эти затраты на разносить на сырье а сразу на партию ГП ?
тогда фактическая стоимость сырья будет не верна
← →
Думкин © (2004-04-16 12:45) [171]> Polevi © (16.04.04 12:42) [170]
Видимо, при полном порядке считаться правильно должно сразу, например. А если не так - кого-то наказать, для начала.
← →
Polevi © (2004-04-16 12:49) [172]>Думкин © (16.04.04 12:45) [171]
наказать нельзя, минимизируются складские запасы, пришло сырье - сразу в цех, а стоимость таможенных услуг может быть еще неизвестна.. это в теории все здорово и красиво получается..
← →
Думкин © (2004-04-16 12:55) [173]> Polevi © (16.04.04 12:49) [172]
Не спорю, я в этом недавно - но уже многое поражает.
← →
DiamondShark © (2004-04-16 13:01) [174]
> то есть вы предлагаете эти затраты на разносить на сырье
> а сразу на партию ГП ?
Да.
> тогда фактическая стоимость сырья будет не верна
А кого она волнует?
Будет верна фактическая себестоимость продукта. Тем более, что:
> а стоимость таможенных услуг может быть еще неизвестна..
← →
Polevi © (2004-04-16 13:12) [175]>DiamondShark © (16.04.04 13:01) [174]
проблема в том что эта партия сырья в дальнейшем может быть использована для производства, то есть она не израсходовалась сразу целиком..
← →
euru © (2004-04-16 13:16) [176]>Polevi © (16.04.04 09:35) [157]
>из этого сырья сварили ГП,
случайно не варка ли пива подразумевается?
← →
Digitman © (2004-04-16 13:19) [177]
> kaif
Ашот, стандартная панель редактирования записей в справочниках в своем алгоритме имеет ощутимо неприятные особенности
1) в not-null-атрибут невозможно ввести пустое значение, в то время как фигурирует вполне оправданная рекомендация не создавать по возможности атрибуты с признаком not-null = false
в то же время, если атрибут создается с признаком not-null, в ISQL-скрипте ты явно генерируешь дифолт-значения для таких полей
вероятно, следует либо отказаться от предупреждения юзера о незаполненном not-null-атрибуте, либо подставлять в поле редактирования атрибута дифолт-значение, либо генерировать сиквел-запрос на вставку/апдейт записи таким образом, чтобы опущеные юзером поля в запросе не фигурировали
2) непосредственно перед вставкой/модификацией не выполняется двусторонний trim для значений строковых атрибутов ... согласись, хранить в полях записей незначащие пробелы неразумно
← →
DiamondShark © (2004-04-16 13:24) [178]
> проблема в том что эта партия сырья в дальнейшем может быть
> использована для производства, то есть она не израсходовалась
> сразу целиком..
Тогда должен быть организован натуральный учёт.
Часть суммы будет отнесена на себестоимость продукта , а часть -- на сырьё на складе, которая потом всё равно будет перенесена на себестоимость.
← →
Polevi © (2004-04-16 13:39) [179]>euru © (16.04.04 13:16) [176]
это имеет значение ?
>DiamondShark © (16.04.04 13:24) [178]
то есть в вашей практике вы обходитесь без перепроведения ?
← →
euru © (2004-04-16 13:48) [180]>Polevi © (16.04.04 13:39) [179]
К обсуждаемой теме это не имеет никакого значения.
Просто у нас варка ГП - это варка пива.
← →
Danilka © (2004-04-16 14:01) [181][179] Polevi © (16.04.04 13:39)
> то есть в вашей практике вы обходитесь без перепроведения?
Судя по статье, ссылку на которую дал Думкин, в аксапте и других буржуйских системах перепроведения нет, а пользуюцца ими во всем мире..
[165] serge35 (16.04.04 11:32)
> > А сейчас есть "субконто" для этого.
> Несколько постов назад это слово было раскритиковано в пух
> и прах.
Да я его вообще-то смысл имел ввиду, а не само слово. То, что компьютеры дали возможность аналитику делать не через субсчета, а более совершенным способом.
← →
kaif © (2004-04-16 14:16) [182]serge35 (16.04.04 10:38) [160]
Я еще 2 года назад написал генератор текста хранимых процедур, но не кричу об этом на весь Инет. Потому, что это всего лишь повседневная, рутинная работа программиста.
Этот генератор процедур я тоже написал два года назад. И я не кричу на весь инет о том, что я его смог написать. Я сообщаю о том, что я применил этот прием для организации виртуальных бухгалтерских операций на основании шаблонов. Что позволило в двухзвенной модели добиться проведения документов без того, чтобы это делалось при помощи скрипта на клиенте (как это делает 1С v 7.7) или скрипта в 3-звенке.
Причем сообщаю это в ответ на Ваш вопрос о том, какие именно проблемы были решены. Могу добавить, что ни одна существующая система такэту проблему не решала. Это решение стало возможным благодаря особенности InterBase: в нем имеется команда SUSPEND, позволяющая с помощью XP имитировать обычную таблицу для конструкции
INSERT .. INTO .. SELECT .. FROM <таблица или процедура>
И вообще у меня такое ощущение, что все я почему-то Вас раздражаю чем-то лично. Скорее всего Вы занимаетесь разработкой похожей задачи. Я угадал?
← →
serge35 (2004-04-16 14:33) [183]Я занимаюсь устранением последствий работы "гениальных" идей в области финансов.
← →
DiamondShark © (2004-04-16 14:55) [184]
> Polevi © (16.04.04 13:39) [179]
> то есть в вашей практике вы обходитесь без перепроведения ?
Да. Долго воевал с бухами. Правда, на моей стороне были манагеры, которым важнее было чтобы учёт отражал фактическое движение товара и информации о нём.
Сильно помогло и то, что требовался точный натуральный учёт. По самой специфике задачи.
Правда, я зарёкся связываться с учётными системами ;-)
← →
kaif © (2004-04-16 15:01) [185]serge35 (16.04.04 14:33) [183]
Я занимаюсь устранением последствий работы "гениальных" идей в области финансов.
А можно конкретнее?
← →
Polevi © (2004-04-16 15:03) [186]>euru © (16.04.04 13:48) [180]
а у нас - варка бытовой химии
← →
kaif © (2004-04-16 15:06) [187]2 serge35 (16.04.04 14:33) [183]
Я пока не вижу от Вас никакой критики по существу. Вы смотрели систему Allegro? Вы читали описание? Или Ваши мнения строятся на Ваших предубеждениях и телепатических способностях?
Что именно в Allegro Вы находите вредным для правильного учета? Я тоже занимаюсь устранением последствий работы "гениальных" идей в области финансов. Идей Карла Маркса и Фридриха Энгельса, в основном. И МИНФИНА, в частности.
← →
serge35 (2004-04-16 15:09) [188]> А можно конкретнее?
Можно.
Некая фирма решила поставить Oracle Applications, для этого наняла другую фирму, которая сделала конфигурацию.
Теперь несколько компаний разребают то, что наворотила компания - разработчик конфигурации.
← →
Polevi © (2004-04-16 15:12) [189]>serge35 (16.04.04 15:09) [188]
хорошо что некая фирма нашла вас, иначе ей пришлось бы туго
← →
euru © (2004-04-16 15:15) [190]>Polevi © (16.04.04 15:03) [186]
Не повезло - много не выпьешь (не съешь).
У нас каждый месяц к зарплате выдается ящик пива.
Кстати, бух. учет ведется на SAP R/3.
← →
serge35 (2004-04-16 15:23) [191]С SAP/R3 пока еще никто не обращался.
Но много организаций обращаются с несложными на первый взгляд вопросами, типа запросы стали медленно работать, ошибки в отчетах.
Начинаешь разбираться с базой - волосы дыбом становятся.
Спрашиваешь, кто им сделал базу, отвечают, что был один умелец, правда недавно уволился и т.д.
← →
kaif © (2004-04-16 15:24) [192]2 serge35 (16.04.04 15:09) [188]
Ну это довольно типичная ситуация. Но какое это имеет отношение к Allegro ?
Я разгребал точно такую ситуацию, когда нагородили нечто в 1С. Так я познакомился с 1С. Очнень плотно. И понял, что нужно писать Allegro.
← →
Polevi © (2004-04-16 15:28) [193]>serge35 (16.04.04 15:23) [191]
как изветсно если руки кривые можно изгадить любую систему
← →
serge35 (2004-04-16 15:29) [194]Надеюсь, что мне никогда не придется разбираться с Алегро.
← →
serge35 (2004-04-16 15:30) [195]> как изветсно если руки кривые можно изгадить любую систему
Алегро, видимо будет исключением.
← →
Тимохов © (2004-04-16 15:34) [196]
> serge35 (16.04.04 15:30) [195]
Уважаемый, ну так же тоже нельзя - насколько я понимаю, вы обсуждаемой системы не видели и основываетесь только на предположениях...
← →
Anatoly Podgoretsky © (2004-04-16 15:35) [197]serge35 (16.04.04 15:30) [195]
Нет, тебе намекнули - для того что бы сделать бардак система не виновата. Она может благоприятсвовать этому или сопротивляться.
← →
euru © (2004-04-16 15:44) [198]>serge35 (16.04.04 15:23) [191]
>С SAP/R3 пока еще никто не обращался.
Если проект с использованием SAP R/3 уже доведен до эксплуатации, то вряд ли вообще когда-либо обратятся.
← →
kaif © (2004-04-16 15:44) [199]Вот, к примеру, одно аналитическое поле в бухгалтерской подсистеме проводок, которое (видит Бог!) мне так сложно отстаивать (проще нагородить 5 шт!) - попытка не допустить бардака априори.
:)
Allegro - это не список того, что "можно сделать", а список жеских ограничений, чего "сделать нельзя ни при каких условиях". Иначе сложную систему не построить.
← →
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 сек.
Тогда я решил придерживаться этого правила и ввел жеское идеологическое ограничение: шаблон проводки не имеет доступа к оборотам или остаткам, но только к полям документов. А какие данные в этих полях на момент перепроведения - дело конфигурирующего.
← →
kombat © (2004-04-17 17:30) [229]2 kaif © (17.04.04 16:54) [225]
мое мнение касательно "периодических/исторических реквизитов" таково - они нужны именно для удобства получения какой-то информации на дату, будь то название котрагента, цена товара или курс доллара. Но уже в документах способ их использования делится на две части: все данные что не влияют на расчеты (финансовые результаты) получаются в документе по ссылке, а те реквизиты которые влияют на расчеты получают из справочника и копируются в документ, т.е. отвязывают от справочника.
Конечно все это на усмотрение разработчика конфы, он может сделать и не правильно. Но может не стоит уж очень понижать его уровень влияния на то что и как нужно делать. Ведь та же 1С не отвечает за действия криворуких внедренцев, она лишь дает инструменты.
← →
kombat © (2004-04-17 17:46) [230]нужен механизм работы именно с реквизитами которые не копируются а получаются по ID элемента справочника
← →
kaif © (2004-04-17 17:58) [231]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 таблицах разных классов. Он "разбирается" и "собирается". Вероятно я плохо изложил этот момент в документации. Если столько вопросов на эту тему.
← →
Petr V. Abramov © (2004-04-17 17:59) [232]> kaif © (17.04.04 17:29) [228]
Идея очень здравая. Но
> и конфигурирующий всегда может написать процедуру, которая это
> сделает с максимально возможной скоростью.
А может и не написать. Что тогда? Можно перепровести, хотя бы за 3 дня?
← →
kaif © (2004-04-17 18:00) [233]2 kombat © (17.04.04 17:30) [229]
Я подумаю на этот счет. Мне нужно несколько дней. Я изложу свою точку зрения. Возможно Вы и правы. Я сейчас не помню то соображение, которое меня отвергло от такой реализации.
← →
kaif © (2004-04-17 18:03) [234]Petr V. Abramov © (17.04.04 17:59) [232]
> kaif © (17.04.04 17:29) [228]
Идея очень здравая. Но
> и конфигурирующий всегда может написать процедуру, которая это
> сделает с максимально возможной скоростью.
А может и не написать. Что тогда? Можно перепровести, хотя бы за 3 дня?
Я не понял вопроса. Конфигурирующий обязан такое написать. Если он не напишет процедуру ПриПроведении() в 1С тоже ничего проводиться не будет вообще.
Или Вы полагаете, что 1С что-то сама делает?
← →
kaif © (2004-04-17 18:10) [235]Когда я говорю, что конфитгурирующий что-то делает, я имею в виду скрипт, кторый он написал, когда "конфигурировал". Скрипт срабатывает сам. Всегда можно написать хранимую процедуру (я рекомендую это именно так делать), которая изменяет данные в каких-то документах в соответствии с новыми условиями. Эта процедура работает на сервере. И работает в любом случае быстрее, чем 3000-кратный вызов процедуры, которая опирается на предыдущий остаток и создает проводку, которая меняет остаток для следующего вызова той же процедуры. Это быстрее в тысячи раз. Как бы программист не старался написать тяп-ляп, это будет работать быстрее в тысячи раз, чем тупое перепроведение всех документов.
← →
kaif © (2004-04-17 18:26) [236]2 kombat © (17.04.04 17:46) [230]
Такой вопрос. В 1С я не помню, как сделано.
Откуда берется дата для "исторического атрибута"? Например, директор поручил менеджеру отредактировать налоговый номер. То сделал это с опозданием на неделю.
Какая дата (ввода данных или дата изменения налогового номера?) должна стать частью автоматичсеки формируемого "исторического атрибута"?
Или нужна настройка таких атрибутов типа птички "обязательно запрашивать дату, считающуюся датой начала действия нового значения атрибута"?
Нужен ли тогда запрет на редактирование истории?
Что делать с документами, которые уже использовали неправильное значение атрибута (которое нужно редактировать)?
Не будет ли юзер интерпретировать исторический атрибут, защищенный копированием в документ, следующим образом: я изменил значение исторического курса валюты, почему у меня документы не пересчитались? И звать программиста, чтобы тат "исправил" положение?
Пока столько вопросов.
← →
Petr V. Abramov © (2004-04-17 18:27) [237]> kaif © (17.04.04 17:58) [231]
> Но ведь 1С - не самая плохая система?
Вроде в Ваш адрес слово "ацтой" не фигурировало :)
> Можно сказать даже лучшая из всех на сегодня.
Не можно :) Просто самая раскрученная.
> что один объект (товар) может одновременно быть строкой в 3
> или в 5 таблицах разных классов. Он "разбирается"
> и "собирается".
Если Вы против того, чтобы в одной таблице сосуществовали и товары ("Г... куриное") и их группировки ("Удобрения органические"), но не против того, чтобы группировки были иерархическими - тогда я поддерживаю. Иначе - не понял :)
← →
kaif © (2004-04-17 18:46) [238]Еще вот что.
Некоторые воспринимают изложенные подходы так, будто я не уважаю программиста и считаю его кретином. Это вовсе не так, скорее наоборот - я многих возможностей лишил юзера, рассчитывая на высокое искусство программиста. Я исключаю те возможности, которые приводят фатально к конфликту программиста с юзером. Юзер считает, что "если так можно, то почему бы не". А программист (опытный) - против и теряет заказчика. Неопытный сохраняет заказчика, идя у него на поводу, но становится, как правило, жертвой юзера.
Юзеры обычно не жалуюся на "отсустствие" каких-то возможностей. Они купили этот продукт и он их, следовательно, устроил по цене и возможностям. Они как правило высказываются о недостатках программы в виде пожелений, а не требований. Но если они получают какие-то дополнительные возможности, например, городить папки в справочнике товаров, а потом получают отказ на пожелание "собрать отчет", то они очень обижаются, так как их многодневная и честная работа по "классификации" товаров оказывается выброшенной в мусорный ящик.
Например, они создали такоую иерархию (без дураков!):Кроссовки
Мужские
Черные
Коричневые
Женские
Черные
Коричневые
Сапоги
Кожаные
Мужские
Черные
Коричневые
Женские
Черные
Коричневые
Кожзам
Мужские
Черные
Коричневые
Женские
черные
Коричневые
Лыжные ботинки
Черные
Коричневые
Красные
Туфли (по цветам вообще не дели - много слишком)
Мужские
Женские
--------------
И теперь хотят отчет об остатках на складе с группировкой по цвету. А цвет оказался в дереве на разных иерархиях. И в разных регистрах букв набранный иногда. И иногда какие-то буквы английские. И не всегда вообще присуствует.
Программист пришел, покорпел, написал. Работает долго (с его точки зрения), но все довольны.
Теперь они еще "что-то добавили" в справочник.
Отчет не работает (в лучшем случае) или работает, но выдает неправильные цифры.
Зовут опять программиста. Тот начинает нервничать. Но делает.
Договариваются "придерживаться таких-то правил".
Через 2 месяца пара менеджеров уходит в декретный отпуск.
Новые менеджеры. Опять ошибки. Зовут программиста.
Программист обижается на то, что новые менеджеры его называют "компьютерщиком", говорит, что они дуры, хлопает дверью и уходит, зарекшись никогда и ни при каких условиях не браться за коммерческие заказы!
А теперь покажите, как такое возможно в Allegro, если там нет иерархических справочников вообще.
← →
kombat © (2004-04-17 18:49) [239]2 kaif © (17.04.04 18:26) [236]
Как это сделано в 1С
Периодический реквизит это таблица вида
ДатаНачалаДействияРеквизита ЗначениеРеквизита
именно начала действия а не дата ввода юзером
История может редактироваться вручную, так же её могут писать документы. Если значение на дату уже есть, то он изменяется на новое
>> Что делать с документами, которые уже использовали неправильное значение атрибута (которое нужно редактировать)?
А ничего не делать, все периодические значения (которые работают по ссылке на ID) могут быть использованы только для печатных форм (для отображения), т.е. документ просто распечатывается заново. А те которые были скопированы в документ уже вообще к справочнику никакого отношения не имеют.
Вообще периодика нужна только для печати и подстановки значений.
>> Не будет ли юзер интерпретировать исторический атрибут, защищенный копированием в документ, следующим образом: я изменил значение исторического курса валюты, почему у меня документы не пересчитались? И звать программиста, чтобы тат "исправил" положение?
А вот это задача програмиста (или helpа) расказать пользователю что скопированный реквизит уже никак не связан со справочником и не обязан пересчитывать все.
← →
kombat © (2004-04-17 18:49) [240]а насчет иерархии в справочнике, то она нужна как минимум для таких случаев как справочник Контрагенты. Где есть Папки "Покупатели", "Поставщики" и пр. и элементы - сами фирмы. Именно Папки а не элементы под видом папок. Пользователь не может выбрать Папку как значение в документ или отчет. Они нужны только для визуального разграничения. Это много удобнее разделить тысячу контрагентов по папкам (как документы, Вы же не скидываете в один список Приходные накладные и банковские выписки) чем искать в общей куче. При всем при этом все записи показываются если мы стаем на вершину дерева и можно искать среди всех а не только в папке.
← →
kombat © (2004-04-17 18:50) [241]а вообще спасибо Вам хотя бы за то что наконец-то почвилясь интересная темы для обсуждения на этом форуме
← →
kombat © (2004-04-17 18:50) [242]появилась тема
← →
kaif © (2004-04-17 18:54) [243]2 Petr V. Abramov © (17.04.04 18:27) [237]
Давайте договоримся так.
Пункт1.1
Группировки если иерархические, но в дальнейшем используются как классификации, то такие классификации оказываются не полными и отчеты по ним поддерживаться программистами не будут ни при каких условиях.
Это запишем первой строкой условного "договора между заказчиком и программистом". Тогда я это тобавлю в систему на уровень интерфейса, доступного юзеру в составе оболочки Allegro. Если программисты потеряют половину заказчиков, прочитавших такой пункт - я не виноват. Идет?
← →
kombat © (2004-04-17 19:00) [244]2 kaif © (17.04.04 18:46) [238]
в этом случае Мужские и Черные это однозначно должны быть ссылками на соответствующие справочники из Справочника
Товары
ID НаименованиеТовара Цвет_ID Тип_ID
Тут я с иерархией класов согласен.
и задача програмиста в том чтобы юзеру не пришлось городить такую иерархию как Вы показали а достаточно было просто выбрать значение в соответствующее поле.
Ведь если такое поле будет, то юзер не станет вводить товар "Черные" с значением поля Цвет "Черный".
иерархия это не ссылка товара на верхний товар, а ссылка товара на Папку
← →
Polevi © (2004-04-17 19:08) [245]>[238] kaif © (17.04.04 18:46)
эта проблема решается сущностью КодТовара
каждый товар в дереве кодируется
допустим кодируем по 2 признакам - Sex (Male, Female) и Color (Black,White)
договариемся о структуре кода и тогда сапоги мужские черные будут иметь код MB
у меня сделано именно так, очень удобно, в структуру кода можно добавлять новые поля и значения этих полей
соотв. поднимаются любые группировки
← →
kombat © (2004-04-17 19:09) [246]Папки нельзя выбрать как значение в документ и нельзя использовать как значение отбора в отчете. В той же 1С это кстати так и сделано. Они служат для визуального разделения справочника, как возможность, но не приказ программисту который боится испугать своих заказчиков.
Кстати. в отчетах их тоже можно использовать, просто это немного сложнее. А документах однозначно нет.
← →
kaif © (2004-04-17 19:10) [247]2 kombat © (17.04.04 18:49) [240]
Мне видится такая иерархия классов:
Контрагенты
Фирмы
Частные лица
Разделение Поставщиков и Покупателей по папкам приводит к известному противоречию: некоторые поставщики одновременно являются и покупателями тоже. Поэтому их попытаются юзеры внести в систему 2 раза. Если же какая-то уникальность этому восприпятствует, то они найдут хакерский выход. Например, в ИНН добавят пробел или точку.
Признак Поставщик/Покупатель является атрибутом, а не способом классификации. И этот атрибут может принимать множетсво значений:
-поставщик
-покупатель
-поставщик и покупатель
-постоянный поставщик
и так далее...
Если порассуждать в этом направлении, то мы вообще обнаружим, что здеь не один, а целых 3 атрибута:
-поставщик (Да/Нет)
-покупатель (Да/Нет)
-особая категория (ссылка на справочник таких категорий)
Это и есть строгое хранение данных, позволяющее в будущем одним SQL-запросом собрать по документам или таблице проводок полный отчет типа:
ВСЕ ПОКУПАТЕЛИ, КОТОРЫЕ ЗАДОЛЖАЛИ СУММУ СВЫШЕ $100 БОЛЕЕ, ЧЕМ 1 МЕСЯЦ.
А как собрать этот отчет по папочкам?
Другое дело, что большие списки плохо обозреваемы и нужны какие-то виды фильтрации и усовершенствованная навигация по сравочникам. Согласен, что в Allegro не все возможности задействованы. Например, нет принципиальных преград для того, чтобы развернуть существующие уже атрибуты в дерево. Это я готов реализовать, но несколько попозже. Сейчас у меня есть ряд более насущных задач. Фильтрация в Allegro имеется. Попробуйте вызвать фильтр. Так что контрагента юзер сможет найти. Пусть не так элегантно, как если бы перед ним было привычное ему дерево. Но если это такая страшная проблема в каком-то случае, конфигурирующий и сейчас может сделать свой интерфейс (окно) для этих нужд, а не юзать стандартный компонент Allegro.
← →
Сергей Суровцев. (2004-04-17 19:16) [248]>Думкин © (17.04.04 13:06) [214]
>Вывод один: или буржуинские программисты себя не уважают
>либо ... расшифруй.
>Я вот одного не понимаю, делать все через нелитературное
>место - это что местная гордость какая-то? Равно как и с
>лицензионностью программ.
>И меня перепроводкка интересует - не как программная фича,
>а как именно нормальный подход, в русле той же Аксапрты. Вот
>зачем он нужен?
>Я все таки про перепроводки ответ пока не понял. Мне кажется
>(именно кажется), что это все-таки несовершенство не
>программерского обеспечения и не существующих законов - а в
>"глупости" действий приводящих к оному - остальное только
>способствует этому.
Нежнее Виктор. Еще нежнее. (с)
Вот простой пример токой необходимости. Есть фирма торговая с
большим складом. Выдали клиенту накладную, поехал он забирать
товар. А на складе углядел расцветку получше. Что делать?
Без перепроведения - создать новый документ - отказ клинта,
а затем еще один - новая накладная. С перепроведением -
войти в уже готовую и исправить строку. Что лучше?
А как тебе ставки налогов, вводимые задним числом? Есть, поверь
и такое. Буржуям это и в страшном сне не привидится.
Очень часто народ играет с цифрами. Ввели, посмотрели, результат
не очень, переиграли, исправили проводки и т.д. Это, конечно,
не в мат.учете, а в основном по налогам, но ве же перепроводки
и еще какие.
А даже без всякого перепроведения, просто возможность
посмотреть документ, по которому сделана проводка простым
нажатием на эту самую проводку? Речь же была именно о сохранении
связи, а уж как ее использовать, вопрос другой.
>kombat © (17.04.04 17:30) [229]
>мое мнение касательно "периодических/исторических реквизитов"
>таково - они нужны именно для удобства получения какой-то
>информации на дату, будь то название котрагента, цена товара
>или курс доллара.
Исторические справочнике в системе, конечно нужны, те же
курсы валют. И храниться в них должны только действительно
необходимые вещи вроде ставок налогов. А всякие цены, реквизиты
контрагентов и прочее... Невозможно даже представить тот
объем информации который тогда придется хранить. Каша получится.
>kaif © (17.04.04 17:29) [228]
Мы, честно говоря, вообще отказались от автоматический
корректировки после перепроводок. Если бухгалтер ее сделал,
пусть будьет добр исправить последствия. Это во-первых заставляет
его трижды подумать, а во-вторых ни обна проводка в системе не
должна поменяться иначе как по сознательному действию бухгалтера
ибо он отвечает за свои цифры почти головой.
Как я понял, промежуточные остатки Вы не храните, а остатки
персчитываете "на лету", поправьте, если не так. А как же быть
с амортизацией? Тоже "на лету"? Со всеми переоценками и сменой
норм? Каюсь, систему еще толком не смотрел, хочется найти период
поспокойнее. Пока только скачал.
← →
Polevi © (2004-04-17 19:18) [249]> [247] kaif © (17.04.04 19:10)
> ВСЕ ПОКУПАТЕЛИ, КОТОРЫЕ ЗАДОЛЖАЛИ СУММУ СВЫШЕ $100 БОЛЕЕ, ЧЕМ 1 МЕСЯЦ.
это делается запросом к таблице проводок, иерархия тут ни причем, не так ли ?
таким образом мы полчили некий список id
> А как собрать этот отчет по папочкам?
для этого достаточно написать ОДНУ УНИВЕРСАЛЬНУЮ процедуру, которая на входе будет получать дерево и список id, и возвращать дерево только с теми листьями, id которых есть в списке
← →
kaif © (2004-04-17 19:27) [250]kombat © (17.04.04 19:09) [246]
Папки нельзя выбрать как значение в документ и нельзя использовать как значение отбора в отчете. В той же 1С это кстати так и сделано. Они служат для визуального разделения справочника, как возможность, но не приказ программисту который боится испугать своих заказчиков.
Проблема в 1С начинается, если имеется несколько атрибутов, которые NOT NULL и имеют уникальность, а папки лежат в той же таблице, что и все остальные элементы. Ну да ладно, это проблема их реализации. Согласен, что таблица папок - вещь отдельная. Но я не о том, что невозможно это организовать. Я о том, что нельзя так организовывать справоники, если потом хочется делать отчеты с группировками по папкам.
Кстати. в отчетах их тоже можно использовать, просто это немного сложнее. А документах однозначно нет.
Именно в этом все дело. В 1С есть некий экзотический "язык запросов", который позволяет задействовать эти папочки в финансовых результатах. Если классификации неполные, конечные отчеты с большой вероятностью будут ложными. И никакого способа проверить, правильно ли собирается отчет, кроме ручного не будет.
Иерархический справочник сразу создает искушение вообще не создавать никаких классов и не ломать голову над этим, переложив это все НА ЮЗЕРА. Я не призываю отказаться от иерархических справочников тех программистов, кто сейчас пишет свои программы в Delphi. Поддержка классов наподобие Allegro-вских требует больших программных ухищрений и множества таблиц в базе данных. И такая реализация в Delphi будет слишком дорогостоящей. Возможно, имеющиеся задачи в своей постановке и не претендуют на такое строгое решение.
Но что касается Allegro, я предлагаю попробовать использовать именно то, что предлагается, а потом уже судить о том, насколько это удобно или нет конечному юзеру, у которого имеются потребности в строгом анализе по атрибутам и который сам отверг 1С, как систему, неподходящую для решения его задачи. Я не замечал, чтобы юзеры во что бы то ни стало требовали иерархического справочника. Заказчики - да, но юзеры - нет. А у заказчика всегда можно уточнить задачу. Может ему Allegro вообще не нужно. Может его и 1С устроит. Важно, чтобы он знал, что теряет и что при этом получает взамен.
← →
kaif © (2004-04-17 19:44) [251]2 Polevi © (17.04.04 19:18) [249]
Я уже объяснил, почему так делать нельзя. Поставщики и Покупатели это не 2 разные альтернативы, которые позволяют всех разносить "по папочкам", а сложная атрибутика, допускающая то, что Поставщик и Покупатель выступают в одном лице. Это приведет к тому, что юзер "для удобства" создаст дубликат в спрвочнике. А если ему попытаться помешать, то он эту преграду обойдет. И отчет будет непоным или неверным. Я уже не говорю о том, что такая "функция" хорошо в 1Сv7.7 пишется, а в SQL-ориентированной двухзвенной системе как правило это равносильно переносу любой обработки на клиент.
2 Сергей Суровцев. (17.04.04 19:16) [248]
Как я понял, промежуточные остатки Вы не храните, а остатки
персчитываете "на лету", поправьте, если не так. А как же быть
с амортизацией? Тоже "на лету"? Со всеми переоценками и сменой
норм?
Для амортизаций нужно завести соответствующий тип доркумента. И в нем делать все расчеты. Затем этот документ проводиться тем же линейным способом. Более того, так как Allegro допускает "отрезание базы" (создание новой), а история амортизации нужна как с законодательной, так и с практической точки зрения, хранение ее в документах обеспечивает все информационные потребности при том, что база периодически (скажем каждый год) освобождается от уже неактуальной (старой) информации (движение товаров, финансовые операции и т.п.).
Насчет перепроведения. Allegro даже позволяет настроить шаблоны так, чтобы до какой-то даты документы какого-то типа проводились по-одному, а после нее - иначе. Это бывает нужно при резкой смене законодательства или изменении характера деятельности в процессе учета.
← →
Petr V. Abramov © (2004-04-17 19:53) [252]> kaif
> Я не понял вопроса. Конфигурирующий обязан такое написать.
> Если он не напишет процедуру ПриПроведении() в 1С тоже ничего
> проводиться не будет вообще.
Я подразумевал, что кроме "ПриПроведении()" автоматом вызывается некая универсальная (и поэтому медленная) процедура, которая отследит зависимости и перепроведет то, что надо. И именно ее программист может (для данного вида документа) заменить своей, более оптимальной в данном конкретном случае. С возможностью вызова "inherited". Или это не так?
Если это действительно не так то, писатель "ПриПроведении()" должен ручками учесть все возможные зависимости. И, что еще хуже, все зависимости, которые появятся в будущем. Или при добавлении нового вида документа или вида операции, лазать по базе и искать, а кто же должнен учитывать его (нового документа) наличие. Похоже, при таком подходе при увеличении количества видов документов сложность разработки будет расти по экспоненте. Хотя при ориентации на малый бизнес это, может, и не критично.
IMHO и если я все правильно понял.
← →
kaif © (2004-04-17 20:16) [253]2 Petr V. Abramov © (17.04.04 19:53) [252]
Разумеется, решение "перепроводить все" кажется более надежным. Ничего не надо знать и ни во что вникать. У каждого документа будет свое "ПриПроведении", которые написали возможно даже разные программисты. По Вашему это может работать? А если все же где-то произойдет ошибка? Например, то же пресловутое деление на 0. Отменять все перепроведение? Что вообще делать? Придется звать программиста, который так или иначе займется "отслеживанием всех возможных связей".
Та же логика, которую предлагаю я очень проста. Она наоборот полностью развязывает проблемы. В Allegro имеется четко упорядоченны список "расчетов", которые конфигурирующий регистрирует в этом списке. Имеется последовательность: список запускается сверху вниз. Конфигурирующий должен всего лишь иметь голову на плечах и представлять какой расчет после которого следует производить по логике вещей. Например, если он наконфигурил 2 расчета:
-перерасчет себестоимости
-закрытие всех счетов
то разумеется, сначала нужно сделать первое, а уже затем, второе.
Моя практика показывает, что в большинстве задач вообще не требуется никаких перерасчетов. Или всего один.
А вот возможность перепроведения отдельного документа нужна практически всегда.
А так как у каждого типа "расчета" имеется своя "точка актуальности" и ею можно управлять в процессе перерасчета, логика получается простой.
Часто необходимость перерасчетов бывает вызвана простым недоразумением. Например, совсем необязательно при списании средней себестоимости проданных товаров всегда списывать точные цифры. Иногда эти цифры могут быть завышены или занижены. Важно, чтобы "в конечном итоге" вся стоимость проданных товаров когда-нибудь списалась. Если же ошибки имеются, но не превышают каких-то процентов, то в соответствии с ПРИНЦИПОМ СУЩЕСТВЕННОСТИ GAAP не следует на эти уточнения вообще заморачиваться.
А те, кто заморачиваются (та же 1С), имеют потом тысячи товаров с отрицательной стоимостью и сумасшедшие прибыли, так как юзеры вынуждены были из-за тормозов в какой-то момент "отключать перепроведение" вообще или остановить бизнес.
В результате "хотели как лучше", а "получилось как всегда".
К сожалению, у нас в стране целый ряд законов провоцирует такие сложные виды учета, как попартионное FIFO. Из-за наличия ГТД в счетах-фактурах. При этом никого видимо не волнует тот факт, что все это бутафория, так как за номера ГТД поставщика не может нести ответственности следующий продавец. Но это не мешает навязывать эти антиправовые по сути схемы даже малому бизнесу, которому этот попартионный учет вообще не нужен, но из-за него они не в состоянии нормально считать свои финансовые результаты.
Так что проблем много. И "слепое перепроведение" решает их в наименьшей степени. Множество проблем нужно решать изменением законодательства, а не напрягать программистов на эти абсурды. Наши власти придумали хорошую схему: мы придумываем проблемы - программисты их решают. Возможно, то что Акцапта вообще не поддерживает всю эту муть, есть ни что иное, как завоевание буржуйских программистов и буржуйского народа, не позволяющего Государству над собой измываться.
← →
kaif © (2004-04-17 20:33) [254]2 Petr V. Abramov © (17.04.04 19:53) [252]
Я кажется понял, к чему Вы клоните. Это довольно любопытная идея. Предположим, имеется некоторый интерфейс, в котором можно расписать квадратиками и стрелочками, что от чего в принципе зависит. Даже точно не зная, что там именно делает каждая процедура ПриПроведении(). А система контролировала бы такие связи и принимала решения сама - что когда перепроводить. Я в общем-то сначала и собирался создать такую систему. Но оказалось, что это очень сложно и для задач малого бизнеса попросту нелепо. Более того, это усложнит сильно программисту жизнь и увеличит тормоза при создании даже самых простых конфигураций, в которых нужен всего 1 перерасчет. Поэтому я этим подходом пожертвовал. Хотя не скрою, он хорош и притягивает к себе творческое воображение. Это нормально. Если бы я городил 3-звенную систему для крупного бизнеса, то я, возможно, так бы и поступил. Но крупный бизнес не останется без программ. Согласитесь. Для монстров найдутся и системы и люди и идеи. Я хотел решить другую задачу. Ту, которую поначалу ставила перед собой 1С - создать дешевый способ автоматизации учета малого бизнеса. Я недавно на семинаре Microsoft слышал последнее заявление Билла Гейтса. Он вообще решил взять курс на то, что малому бизнесу автоматизация учета не нужна. Ему нужен только Office и возможность обмена документами через ресурсы WWW.
← →
kaif © (2004-04-17 20:43) [255]2 Petr V. Abramov © (17.04.04 19:53) [252]
Кстати, в allegro вообще нет процедуры ПриПроведении(), которую нужно писать ручками. Там есть шаблон (схема) проводки, которая настраивается бухгалтером или конфигурирующим. После сохранеения шаблона allergo автоматически генерирует в базе данных текст хранимой процедуры, которая порождает проводки в формате журнала операций. Программисту нужно в модуле документа нужно только вызвать процедуру, передав в нее название таблицы документа, его ID и указатель на компонент транзакции:
procedure MakeEntries(const MainTableName: string; doc_id: integer; ATransaction: TIBTransaction);
и подтвердить транзакцию.
Проводки в Allegro программировать вообще не нужно. А чтобы узнать, что они делают, достаточно взглянуть на их шаблоны. Так как от оборотов и остатков их деятельность не зависит, то программисту очень легко представить, что именно происходит в системе при проведении любого документа.
← →
Petr V. Abramov © (2004-04-17 20:55) [256]> kaif © (17.04.04 20:16) [253]
Ну "перепроводить все" я не призывал.
Я просто пытаюсь понять, из как определяется, что проводить, а что - нет, и можно ли перепровести вообще. В первом приближении это была "процедура, написанная программистом", а выяснилось, что все не так плохо :)
← →
Petr V. Abramov © (2004-04-17 21:05) [257]> kaif © (17.04.04 20:43) [255]
> Так как от оборотов и остатков их деятельность не зависит
А как же мне реализовать "не резервировать товар козлам, которые должны больше 1000 р в течение месяца"?
А автоклиринг при отгрузке товара или поступлении оплаты "без назначения" (то есть "за товар", а по какой отгрузке, решайте сами, ну мы ж свои люди, разберемся")?
← →
kaif © (2004-04-17 23:43) [258]2 Petr V. Abramov © (17.04.04 20:55) [256]
В дополнение к возможностям системы проведения добавлю:
К каждому документу может быть создано несколько шаблонов (обычно так и делается в Allegro), каждый из которых содержит "условие проведения". Это указатель на какое-то целочисленное поле документа, которое должно принять какое-то значение и само это значение. Это позволяет задействовать разные шаблоны при разных условиях, например, продажу за рубли провести по-одному, а за доллары - по другому. Или включить в документ птичку "отгружено" или "зарезервировано". Документ окажется перепроведенным после переключения птички и сохранения документа (обычно вызов MakeEntries используют при нажатии кнопки "сохранить", которая подтверждает транзакцию).
Кстати, можно провести документ, а затем проверить в текущей транзакции, не стало ли какое-то из складских количеств меньше нуля и не дать подтвердить транзакцию (то есть не дать сохранить изменения) если это так. Таким образом, остальные юзеры, работающие в режиме ReadCommitted даже не узнают, что была попытка такой отгрузки.
Так как все происходит путем удаления/добавления в таблицу проводок со ссылкой на DOC_ID, а любые остатки рассчитываются всегда заново при помощи агрегатных SQL-запросов, lock conflict не возникает, даже если несколько юзеров займутся одновременно отгрузкой одного и того же товара (сорок человек на сундук мертвеца!). Причем выигрывает не тот, кто решил раньше начать рисовать документ, а тот, кто успел раньше его закончить и сохранить, что на мой взгляд лучше, чем первый вариант. Но это один из вариантов реализации "резервирования" в виде "перемещения на счет резервного склада" или "перемещения в счет резерва менеджера такого-то". Такие конфигурации я не реализовывал. Я просто говорю, что это возможно так сделать. Без конфликтов, так как в Allegro никакой "таблицы остатков" не ведется, в отличие от некоторых других систем. Разумеется, это требует больше ресурсов сервера. Но зато не может никогда "дать сбой".
А как же мне реализовать "не резервировать товар козлам, которые должны больше 1000 р в течение месяца"?
Если такая задача стоит, то нужно создать специальный тип документа - отчета, куда периодически вносится отчет о должниках (нажатием кнопки или руками) и на основании этого документа уже "не отгружать". Неправильно, чтобы такие вещи выяснялись лишь в тот момент, когда грузовик уже стоит у дверей склада. Кто-то должен заниматься должниками, вежливо предупреждать их о том, что "их отключат" и формировать такой документ "отключенных должников". Тем более, что иногда нужно этот документ будет подправлять руками, так как некоторые должники могут быть "равнее других". Так всегда бывает. Если такие решения принимает "компьютерная программа", это не лучший способ вести бизнес (ИМХО), так как не компьютер должен управлять событиями, а люди.
А автоклиринг при отгрузке товара или поступлении оплаты "без назначения" (то есть "за товар", а по какой отгрузке, решайте сами, ну мы ж свои люди, разберемся")?
Поясните пожалуйста, я не понял, что здесь Вы спрашиваете.
← →
Petr V. Abramov © (2004-04-18 01:24) [259]> kaif © (17.04.04 23:43) [258]
> Поясните пожалуйста, я не понял, что здесь Вы спрашиваете.
Допустим, предоплаты ведутся на одном счете, а дебиторка на другом (довольно частая ситуация). При отгрузке надо списывать со счета "Предоплаты" соотв. сумму и, при ее нехватке, начислять на счет "Дебиторы". На позапрошлой моей работе это еще осложнялось тем, что дебиторку надо было вести в разрезе отгрузок (для анализа старения дебиторки и вздрючивания торгового отдела на сумму, зависящую от величины просрочки платежей)
В любом случае я уже идею понял.
> Кстати, можно провести документ, а затем проверить в текущей
> транзакции,
То есть просто всякого рода проверки проводятся сбоку от процедуры проведения? То есть я могу и остатки затронуть, но о перепроведении голова уже будет болеть у меня, а не у Вас, я правильно понял?
> выигрывает не тот, кто решил раньше начать рисовать документ,
> а тот, кто успел раньше его закончить и сохранить, что на мой
> взгляд лучше, чем первый вариант.
Абсолютно логично
> Если такая задача стоит, то нужно создать специальный тип
> документа - отчета, куда периодически вносится отчет о
> должниках (нажатием кнопки или руками) и на основании этого
> документа уже "не отгружать".
А зачем такой огород? Эта информация вся есть в виде сальдо соотв. счетов.
> Если такие решения принимает "компьютерная программа", это не
> лучший способ вести бизнес (ИМХО),
Система решения не принимает, она рекомендует. Но послать ее подальше со своими рекомендациями может только пользователь с соответствующими правами.
> Без конфликтов, так как в Allegro никакой "таблицы остатков"
> не ведется, в отличие от некоторых других систем. Разумеется,
> это требует больше ресурсов сервера. Но зато не может
> никогда "дать сбой".
То есть если мне надо узнать остаток на вечер сегодня, придется суммировать оборот прям от Царя Гороха?
> Без конфликтов
Вы оптимист (в техническом смысле :) Если "lock conflict не возникает", значит, наверно, в TPB стоИт READ_COMMITED REC_VERSION. А раз так, возможна след. ситуация:
время транзакция
t0 На складе 100 ведер продукции
t1 1 списание 90 ведер
t2 1 проверка остатка (осталось 10 ведер)
t3 2 списание 90 ведер
t4 2 проверка остатка (осталось 10 ведер!)
t5 1 commit
t6 2 commit
Результат: сальдо - в кредите на 80, программист - в ж... (:
← →
Petr V. Abramov © (2004-04-18 01:24) [260]> kaif © (17.04.04 23:43) [258]
> Поясните пожалуйста, я не понял, что здесь Вы спрашиваете.
Допустим, предоплаты ведутся на одном счете, а дебиторка на другом (довольно частая ситуация). При отгрузке надо списывать со счета "Предоплаты" соотв. сумму и, при ее нехватке, начислять на счет "Дебиторы". На позапрошлой моей работе это еще осложнялось тем, что дебиторку надо было вести в разрезе отгрузок (для анализа старения дебиторки и вздрючивания торгового отдела на сумму, зависящую от величины просрочки платежей)
В любом случае я уже идею понял.
> Кстати, можно провести документ, а затем проверить в текущей
> транзакции,
То есть просто всякого рода проверки проводятся сбоку от процедуры проведения? То есть я могу и остатки затронуть, но о перепроведении голова уже будет болеть у меня, а не у Вас, я правильно понял?
> выигрывает не тот, кто решил раньше начать рисовать документ,
> а тот, кто успел раньше его закончить и сохранить, что на мой
> взгляд лучше, чем первый вариант.
Абсолютно логично
> Если такая задача стоит, то нужно создать специальный тип
> документа - отчета, куда периодически вносится отчет о
> должниках (нажатием кнопки или руками) и на основании этого
> документа уже "не отгружать".
А зачем такой огород? Эта информация вся есть в виде сальдо соотв. счетов.
> Если такие решения принимает "компьютерная программа", это не
> лучший способ вести бизнес (ИМХО),
Система решения не принимает, она рекомендует. Но послать ее подальше со своими рекомендациями может только пользователь с соответствующими правами.
> Без конфликтов, так как в Allegro никакой "таблицы остатков"
> не ведется, в отличие от некоторых других систем. Разумеется,
> это требует больше ресурсов сервера. Но зато не может
> никогда "дать сбой".
То есть если мне надо узнать остаток на вечер сегодня, придется суммировать оборот прям от Царя Гороха?
> Без конфликтов
Вы оптимист (в техническом смысле :) Если "lock conflict не возникает", значит, наверно, в TPB стоИт READ_COMMITED REC_VERSION. А раз так, возможна след. ситуация:
время транзакция
t0 На складе 100 ведер продукции
t1 1 списание 90 ведер
t2 1 проверка остатка (осталось 10 ведер)
t3 2 списание 90 ведер
t4 2 проверка остатка (осталось 10 ведер!)
t5 1 commit
t6 2 commit
Результат: сальдо - в кредите на 80, программист - в ж... (:
P.S. Ушел за пивом, жду ответа :)
← →
kaif © (2004-04-18 03:16) [261]Petr V. Abramov © (18.04.04 01:24) [259]
Допустим, предоплаты ведутся на одном счете, а дебиторка на другом (довольно частая ситуация).
Поясните, зачем такое извращение.
То есть просто всякого рода проверки проводятся сбоку от процедуры проведения? То есть я могу и остатки затронуть, но о перепроведении голова уже будет болеть у меня, а не у Вас, я правильно понял?
Я не понимаю, о чем вы говорите здесь. Нету никакой "процедуры проведения". Проведение происходит в момент подтверждения транзакции. Процедурой проведения можете называть все, что происходит до того, включая генерацию новых проводок, проверки и так далее.
А зачем такой огород? Эта информация вся есть в виде сальдо соотв. счетов.
Сальдо счетов содержит только информацию о текщей задолженности. Я Вас так понял, что Вас интересуют те, кто просрочили ее дольше, чем определенное время. А этой информации в сальдо нет. Но ее легко можно получить SQL-запросом. Однако, когда я говорю о создании "черного списка должников" я имею в виду именно возможность отвечать за состав этого списка осознанно. Если же задача стоит более узко и речь идет всего лишь об оперативном запросе текущей задолженности (когда грузовик уже стоит там, где я сказал), то здесь нет вообще никакой проблемы. И я не понимаю, зачем тогда Вы ее вообще подняли.
То есть если мне надо узнать остаток на вечер сегодня, придется суммировать оборот прям от Царя Гороха?
Да, придется. Так устроена система Allegro. Не нравится - не юзайте. Я уже говорил о скорости расчета баланса 100 проводок тыс/сек (на 2ГГц) и о "компактном" способе хранения проводок. Этих ресурсов вполне достаточно для малых фирм, о которых идет речь. Если Вам нужна система управления складом с миллионами транзакций в месяц, с пессимистической моделью доступа к ресурсам и с 20 менеджерами, которые решают одну задачу - зарезервировать/отгрузить товар, то Вам нужна другая система. Можете потом из этой другой системы импортировать данные в Allegro, если Вам нравятся возможности Allegro организовывать финансовую сторону процесса. Но управление складом тогда должно решаться отдельно - возможно на MSSQL или другом "блокировочнике", которые как нельзя лучше приспособлены для таких задач.возможна след. ситуация:
время транзакция
t0 На складе 100 ведер продукции
t1 1 списание 90 ведер
t2 1 проверка остатка (осталось 10 ведер)
t3 2 списание 90 ведер
t4 2 проверка остатка (осталось 10 ведер!)
t5 1 commit
t6 2 commit
Результат: сальдо - в кредите на 80, программист - в ж... (:
В Вашей пессимистической модели возможна. В тех задачах, для которых предназначено Allegro - крайне маловероятна. Разница во времени между проверкой и коммитом составляет максимум десятки миллисекунд. Для того, чтобы то, что Вы говорите, произошло, необходимо, чтобы:
1. Одновременно отгружался один тот же товар. Предположим, вероятность такого события равна 1/100
2. Оба юзера одновременно нажали "сохранить" (с разницей 24 миллисекунды, к примеру). Если в день один менеджер делает даже 100 документов по 10 позиций и таких менеджеров 36 человек (!), то вероятность этого события примерно:
0.024 сек * 10 *100 *36/(24часа*3600 сек) = 1/100
Результирующая вероятность равна произведению этих двух вероятностей, то есть (1/100)*(1/100)=10^-4.
Это означает, что на 10 тыс операций отгрузки придется 1 ошибка, о которой Вы упомянули.
Ей богу легче ее обнаружить и исправить вручную, чем иметь тысячи лок-конфликтов. Я предлагаю опять вернуться к принципам GAAP - ПРИНЦИП РАЦИОНАЛЬНОСТИ. Никакие дополнительные затраты на постановку учета не оправданы, если это программерская самоцель, обходящаяся дороже, чем потери, которые она должна предотвратить.
а потери в данном случае - стоимость отказа клиенту на складе товара, который был уже выписан. Это и так происходит сплошь и рядом, даже в самом соверенной учетной системе по одной причине - не все данные успевают вноситься в компьютерную систему.
Если же Вам во что бы то ни стало нужно уменьшить вероятность такой ошибку до нуля - создайте 36 складов резервирования и перед началом "отгрузки" резервируйте товар "на личном складе менеджера", списывая его с основного склада. Сделайте хоть десять проверок после такой транзакции, если эта ситуация настолько критична. Затем уже спокойно отгружайте с личного склада менеджера, зная, что никто кроме него такую отгрузку уже не сможет произвести.
В мире пессимистических задач важна не теоретическая правильность системы, а ее суммарная отказоустойчивость, складывающаяся из очень большого числа факторов.
Я видел в работе систему, в которой все сделано "правильно" и отгрузить вроде ничего, чего нет невозможно в принципе. Меня позвали, чтобы я разрулил отрицательный остаток, который там возник. Так как система не предполагала такой ситуации в принципе - мне пришлось изрядно повозиться среди ихних 3.5 тысяч хранимых процедур, пока я сумел это починить. Сбой произошел, когда с системой работала пара человек и внесла от силы штук 10 документов. Не верите? Так оно и бывает частенько.
Поэтому я за простоту. Пусть даже допускающую вероятность ошибки в результате "наложения". Юзеры такие вещи прекрасно понимают и их это не раздражает. У них и так весь бизнес - одна сплошная накладка. :)
Как говорил Иисус "Не пришивают заплату новую к платью старому". И платье порвется, и дорогая заплата пропадет.
Не нужно ничего вечно "резервировать" и в последний момент успевать. Нужно завести за правило иметь определенный избыток товара на складе, чтобы нужный товар всегда в наличии имелся. А не бегать к конкуренту быстро-быстро типа "у меня клиент - продай мне пару штук прямо щас - век не забуду". Когда не умеют вести бизнес - потом всегда думают, что программисты их спасут от проблем.
Не спасут.
Склад будет работать на грани того, что половина клиентов уезжает ни с чем, денег в кассе никогда не будет "благодаря планированию денежных средств", программист будет вертеться, как белка в колесе, а клиенты рано или поздно на такую фирму плюнут и пойдут туда, где никто никуда не спешит, все всегда есть, да еще и чашечку кофе предложат.
Извините, если кого задел. К счастью или нет но надеюсь, что здесь больше программистов, чем бизнесменов.
:)
← →
Petr V. Abramov © (2004-04-18 04:45) [262]> Результирующая вероятность равна произведению этих двух
> вероятностей, то есть (1/100)*(1/100)=10^-4.
> Это означает, что на 10 тыс операций отгрузки придется 1
> ошибка, о которой Вы упомянули
Выше на порядок, если не на 2, цифру не помню. Electronically tested, как пишут на презервативах. С временами проведения порядка Вами приведенных. Но с вероятностью конкуренции за остатки ~70%. Законы Мэрфи сильнее закона больших чисел (С), по-моему, Ваше. :)
> Сбой произошел, когда с системой работала пара человек и
> внесла от силы штук 10 документов. Не верите?
Еще как верю. См. про законы Мэрфи :)
> стоимость отказа клиенту на складе товара, который был уже
> выписан.
Советская власть хорошая :). Не агитируйте :) Речь идет об этапе резервирования.
> Нужно завести за правило иметь определенный избыток товара на
> складе, чтобы нужный товар всегда в наличии имелся.
Нужно, еще как нужно. Но вот когда происходит резкий всплеск продаж (при торговле газировкой, например - при резко наступившей засухе :) - лучше по телефону отказать, чем машина приедет, а товара нет. А вот если (пусть с вероятностью 10^-4) склад уйдет в минус, ошибка выяснится как раз когда фура будет стоять у ворот. И будет очень стыдно. А при вот такой "борьбе с урожаем" надежность инф. системы и помогает достичь того, чтоб не было "клиенты рано или поздно на такую фирму плюнут". Ну в общем это все сложно :)
> Ей богу легче ее обнаружить и исправить вручную,
Исправить, может, и легче. А вот обнаружить - ну, мягко говоря, спорно.
> создайте 36 складов резервирования и перед началом "отгрузки"
> резервируйте товар "на личном складе менеджера",
А во это, пардон, через ж...
По-любому у меня нет желания сказать, что Ваша система - плохая. Просто я для себя пытаюсь выяснить границы ее применимости.
> Но управление складом тогда должно решаться отдельно -
> возможно на MSSQL или другом "блокировочнике",
А вот это (на MSSQL) не надо. IB/FB тоже прекрасно умеет блокировать (когда надо, а когда не надо - не умеет :). И если кое-где у нас порою жирно написано, что "IB не блокирует" - это не значит, что блокировок нет, даже если их назвать isc_gbd_tpb_ib_vrotebi_feature. У IB/FB всего лишь нормально развязаны чтение с записью :)
← →
Думкин © (2004-04-18 08:05) [263]> [228] kaif © (17.04.04 17:29)
> 248] Сергей Суровцев. (17.04.04 19:16)
Видимо, вы правы. Я как и говорил, совсем недавно в этом - почти чайник. Но сам подход к обработке документов "задним числом" меня пока настораживает. Как и написал - несовершенство ряда вещей в организации приводит к ряду проблем в автоматизации, разбалтывая опять же организацию, все этот идет слоями - и в итоге имеем кашу, в которой мало кто разбирается, вот мой нынешний работодатель уже давным давно не может просто свести баланс - как выяснилось уже давным-давно, и на весьма немаленькие суммы. Сейчас много общаююсь с нашими менеджерами и вижу, что для них система автоматизавции выступает как нечто левое, в котором они готовы менять что угодно, как угодно и в какой угодно момент, как в справочной помойке. А понимания того, что это должно быть отражением их "реальной" деятельности на всех этапах - не вижу. Переход с 1 на второй уровень известной иерархии. :((
← →
Cobalt © (2004-04-18 09:04) [264]2 Kaif
А у вас в системе есть такая возможность - ставить блокировки на склад?
Мы, например, у себя всегда ставим блокировки при проведении (Уж лучше менеджер увидит сообщение "Попробуй ещё раз!")
← →
Сергей Суровцев. (2004-04-18 09:41) [265]Глянул пока только вскользь. Баланс понравился. Несколько смутили кнопки "ОК" в русскоязычном интерфейсе, отсутствие выбора из справочника двойным щелчком и не совсем ожидаемое поведение полей ввода чисел.
А насчет иерархических справочников... Сама по себе их реализация тривиальна, а возможность использования легко блокируема. Почему бы не оставить решение о его использовании тому самому программисту?
← →
Sergey Masloff (2004-04-18 15:45) [266]Тимохов © (13.04.04 17:24) [11]
>Если нужно сделать серьезную учетную систему, то тут совсем все >по-другому: r3, baan или еще что, причем за совсем нешуточные >деньги.
Вот что я скажу как человек имеющий непосредственное отношение
;-). Как всем известно директор серьезной компании должен ездить на мерседесе с охраной. Не потому что на него кто-то будет покушаться и не потому что ему нравится мерседес - он бы может предпочел роллс-ройс или еще что. Но так НУЖНО - это своего рода неписаный закон. Также и с R3 и BAAN и иже с ними - если предприятие их ставит значит есть деньги на ненужную ерунду -> значит дела у предприятие хороши -> с ним можно иметь дело. Причем я не утрирую, это все именно так. К сожалению множество известных мне фактов подтверждающих мое мнение я не могу привести в открытом форуме (да и не в открытом тоже...)
← →
kaif © (2004-04-18 16:11) [267]Спасибо всем за высказываемые предложения и критику.
К сожалению, иногда просто невозможно одновременно удовлетворить все требования. Некоторые подходы взаимно исключают друг друга. Мне часто приходилось жертвовать маловероятными проблемами во имя простоты и прозрачности решений.
Иногда мне попросту не хватало ума или какого-то опыта. Поверьте, все ваши замечания для меня крайне ценны.
Например:
Cobalt © (18.04.04 09:04) [264]
2 Kaif
А у вас в системе есть такая возможность - ставить блокировки на склад?
Мы, например, у себя всегда ставим блокировки при проведении (Уж лучше менеджер увидит сообщение "Попробуй ещё раз!")
Я уже говорил, что в Allegro будут добавляться новые подсистемы, в частности многомерные регистры.
Я не хотел сильно нагружать бухгалтерскую подсистему несвойственными ей функциями. Тот пример склада, что приведен для обучения, очень прост и примитивен. Разумеется, это учебный пример и его не следует воспринимать, как руководство к тому, как создать серьезную складскую программу.
Существует еще один принцип GAAP: ПРИНЦИП ДЕНЕЖНОГО ИЗМЕРЕНИЯ. Бухгалтерский учет (accounting) оперирует только с данными, имеющими денежное выражение. Поэтому даже тот учет количеств, который я добавил в журнал проводок по большому счету является излишеством, недорогим довеском, позволяющим упростить учет количественных единиц, с которым обычно в малой фирме так или иначе приходится сталкиваться. Но цель бухгалтерской подсистемы Allegro - решение иной задачи, а именно - быстрое и надежное получение наглядного текущего финансового положения всей фирмы в целом (баланс).
Если кто-то посчитает возможным в Allegro создать настоящий склад с блокировками на уровне конфигурации и это решение будет востребовано рынком, он может создать соответствующую "стандартную конфигурацию" и принять участие в проекте gaapinvest. Если же этого никому не захочется делать на уровне конфигурации и никто не верит, что таким способом он мог бы заработать деньги, то тем более непонятно, зачем мне такие вещи в ключать в ядро. Согласитесь, в этом есть логика. Если же чего-то не хватает в ядре для построения таких конфигураций - я готов обсуждать эти проблемы.
Сергей Суровцев. (18.04.04 09:41) [265]
А что можно предложить вместо OK? я готов использовать другие варианты - мне просто часто ничего другого в голову не приходит...
отсутствие выбора из справочника двойным щелчком
А как же вызов элемента на редактирование? Возможно, нужно сделать наоборот - кнопка вызывает на редактирование, а двойной щелчок - выбирает элемент. Но интерфейс справочников в любом случае нужно дорабатываить. С этим я согласен.
и не совсем ожидаемое поведение полей ввода чисел.
Уточните. В чем проблема?
А насчет иерархических справочников... Сама по себе их реализация тривиальна, а возможность использования легко блокируема. Почему бы не оставить решение о его использовании тому самому программисту?
Я еще раз подумаю на эту тему.
Petr V. Abramov © (18.04.04 04:45) [262]
Ваши аргументы убеждают. Такая задача существует (пиковые нагрузки на склад).
Если Вы видите простое решение такой задачи, которым не грех отяготить всех потребителей системы Allegro, я готов обсуждать такое решение и включить его в ядро системы. Соответственно и стоимость Allegro для всех может возрасти в результате таких добавлений.
Есть другой вариант. Если у Вас есть решение - Вы можете реализовать его на уровне конфигурации (это же SQL-система! Я не вклиниваюсь между Вами и базой данных!), а проект gaapinvest возьмется тиражировать такое решение в качестве "стандартной конфигурации для пикового склада". Вы же получите 50% прибыли от продаж этой конфигурации. Идет?
Я включаю в Allegro либо то, что нужно всем (например, баланс), либо то, что невозможно простыми средствами реализовать на уровне конфигурации, но нужно подавляющему большинству.
С уважением.
← →
kaif © (2004-04-18 16:47) [268]2 Petr V. Abramov © (18.04.04 01:24) [260]
Допустим, предоплаты ведутся на одном счете, а дебиторка на другом (довольно частая ситуация).
Я кажется понял, в чем тут дело. Скорее всего проблема вызвана тем, что при начислении НДС в некоторых схемах, когда авансы облагаются НДС (есть такой бред), то приходится их учитывать отдельно от других финансовых операций, чтобы видеть "всю висящую в авансах сумму". Так вот в случае с Allegro эта задача решается очень красиво. Можно создать регистр счетов "Расчеты с контрагентами" с такой системой счетов:
Расчеты с контрагентами
Расчеты с покупателями
Авансы покупателей
Отгружено покупателям
Расчеты с поставщиками
Авансы поставщикам
Получено от поставщиков
Весь регистр привязывается к справочнику контрагентов. И все счета поэтому аналитические. Развернутые сальдо в балансе следует назвать "Счета дебиторов" (слева) и "Счета кредиторов" (справа). В зависимости от характера операции (аванс или платеж после отгрузки) делать начисления на разные счета. При этом всегда можно будет увидеть общую картину по каждому поставщику или покупателю. Или всю картину в целом. Но это очень предварительная схема. Нужно точно понять, в чем экономическая суть проблемы.
Вообще стиль баланса Allegro позволяет развивать сами принципы бухгалтерского учета. Например, не исключено, что даже классический GAAP-баланс неверно показывает финансовое положение фирмы, работающей в основном с одними и теми же контрагентами, но по куче договоров, каждый из которых имеет изолированные экономические отношения (без автоматических встречных зачетов даже в рамках одного контрагента). Об адекватности МИНФИНовского баланса в такой ситуации я вообще молчу. Есть ряд оснований предполагать, что в современном мире постепенно субъектом экономических отношений перестает выступать конкретная фирма и вместо нее таким субъектом становится "проект" или "договор". В конце концов, фирма это тоже всего лишь договор собственников и текущий баланс к нему. Поэтому я не исключаю возможности пересмотра многих даже классических положений в ближайшие годы, особенно в связи с быстрым развитием средств коммуникации, когда одну задачу решают множество фирм одновременно в рамках одного "проекта".
← →
Anatoly Podgoretsky © (2004-04-18 17:24) [269]Кстати для продуктов такого класса хорошим тоном является наличие открытого форума на сайте для разработчиков и пользователей и это очень полезно для продвижения продукта.
← →
kaif © (2004-04-18 17:30) [270]2 Anatoly Podgoretsky © (18.04.04 17:24) [269]
Я очень хочу приделать форум. Вы думаете, народ будет посещать? Я боюсь мертвого форума... Хотя если там обсуждать не только Allegro, но и сами принципиальные проблемы и все, что с этим связано, но, может, и будет какая-то жизнь... У меня нет опыта в создании форумов. В чем главный секрет? И главная пробюлема?
← →
kaif © (2004-04-18 17:33) [271]2 Anatoly Podgoretsky © (18.04.04 17:24) [269]
Мне неловко, что я сейчас нагружаю форум Мастеров. Конечно правильнее сделать свой.
← →
Anatoly Podgoretsky © (2004-04-18 17:34) [272]Сначала будет мертвый, но кто мешает в форуме публиковать мелкие совыеты рекомендации, ты только учти, что от тебя потребуется много сил.
А примеры есть, например форум Франсуа Пьетте, по объему сообщений и по их качеству могут многие только позавидовать. Это автор таких продуктов как ICS Internet Connection Suite и Midware
Просто такой сложный продукт обязан иметь форум, в каком виде - или почтовая рассылка или веб форум или группа новостей.
Удачно если будет одновременно рассылка и веб форум, для этого можно организовать группу на groups.yahoo.com уже готовый интерфейс.
← →
Anatoly Podgoretsky © (2004-04-18 17:36) [273]kaif © (18.04.04 17:33) [271]
Та он уже перерос обычное обсуждение.
Структура форума уже становится неудобной для такого объема да и требуется рахбиение по темам, и уж молчу про персональную поддержку при проблемах с продуктом.
← →
kaif © (2004-04-18 17:37) [274]2 Anatoly Podgoretsky © (18.04.04 17:34) [272]
Спасибо за информацию. Правда половины слов я не понял... Ну да ладно, разберусь.
← →
kaif © (2004-04-18 17:42) [275]Да, я уже вижу, что нужно разбивать вопросы по темам. А заводить на мастерах целый ряд веток на эту тему - неправильно. В конце концов это коммерческий продукт. Я брошу все силы на создание своего форума. Я вот слышал, что можно использовать "готовые форумы". Но моему WebMaster-у эта идея не очень нравится. Я сам колеблюсь, так как мало что в этом понимаю. Многое из того, что я видел популярного сейчас мне вообще не нравится. Что бы Вы посоветовали? Сделать простой свой форум на основе MySQL+php и его развивать или воспользоваться чем-то готовым, и если воспользоваться, то чем?
← →
Anatoly Podgoretsky © (2004-04-18 18:20) [276]Ну я же тебе предложил воспользоваться http://groups.yahoo.com или ты обязательно хочешь именно на своем сайте, но это не обязательно, пускаq за тебя работают специалисты. Там размещено много shareware rus форумов, под базовым названием SWRUS
← →
Petr V. Abramov © (2004-04-18 18:56) [277]kaif © (18.04.04 16:11) [267]
> Ваши аргументы убеждают.
Take it easy :) Я примерил Вашу систему на довольно жестокое OLTP. У меня есть реализация на Oracle. Вернее, код, конечно, принадлежит Компании, тем более, что она передо мной все обязательства выполнила. Но вот идеей и знанием мест нахождения подводных граблей (самые очевидные я Вам продемонстрировал) она практически не владеет.
> Если у Вас есть решение - Вы можете реализовать его на уровне
> конфигурации (это же SQL-система!
Врядли. Именно из-за ядра.
> kaif © (18.04.04 16:47) [268]
> Я кажется понял, в чем тут дело.
Направление мысли - абсолютно верное
> При этом всегда можно будет увидеть общую картину по каждому
> поставщику или покупателю.
Общую-то можно. Но, например, ту же динамику ее старения - нельзя. Но - Take it easy :) Большинство бухгалтеров слов-то таких не знает :)
> Идет?
Я подумаю, как только чуть разгружусь и с хорошими людями посовещаюсь :). А то я уже много кому чего наобещал (:
← →
Сергей Суровцев. (2004-04-19 08:22) [278]>kaif © (18.04.04 16:11) [267]
>А что можно предложить вместо OK?
Я обычно использую "подтвердить" и "отказаться" с зеленым и красным значками. Очень наглядно.
>А как же вызов элемента на редактирование? Возможно, нужно >сделать наоборот - кнопка вызывает на редактирование, а >двойной щелчок - выбирает элемент.
Если есть отдельный режим редактирования справочника, то там конечно двойной щелчек будет вызовом строки на редактирование. По если это список, предоставленый для выбора по логике однозначно ожидается, что при двойном щелчке произойдет выбор.
И еще. Вполне логично, когда после выбора счета, имеющего справочник этот справочник откроется автоматом.
>>и не совсем ожидаемое поведение полей ввода чисел.
>Уточните. В чем проблема?
Обычно если войти в числовое поле и сразу начинать набирать цифры ожидается что старое значение сразу исчезает, а если было движение курсора в поле, то нет. У Вас же старое значение не исчезает и его приходится убирать руками. Это напрягает. :))
Ну и конечно желательно подставлять слой по умолчанию.
← →
MMF © (2004-04-19 09:09) [279](kaif) скачал и попробовал написать маленькую конфигурацию. Появились вопросы и пожелания. У Вас есть форум, + багрепорты куда?
← →
MMF © (2004-04-19 09:30) [280](279+) где можно почитать по ограничениям языка? Столкнулся с кучей ограничений (try except On e:Exception; типизированные константы не поддерживаются, проверка if Acomp is TControl не пашет, RTTI не работает, при запуске под дизайнером "if (AComp.Parent= tabReferences) and (AComp<>Sender) then" работает, а в самой системе - Parent не известен) и т.д. Хотелось бы познакомиться с полным описание чего можно/нельзя. Очень может быть, что я туплю, но ненашел как отлаживать скрипт?
← →
Anatoly Podgoretsky © (2004-04-19 09:39) [281]Ты затронул больной вопрос - документация, от разработчиков сложно ожидать, не из специальность.
← →
MMF © (2004-04-19 11:11) [282]Сделал несколько заметок, пока пробовал:
1) Было бы удобно в окне Метаданные иметь в правой части закладку с информацией из закладки База.Определение для этого объекта.
2) В ISQL как-то странно себя ведет сплиттер
3) Опечатка. Форма "Добавить поле" - типа данных Varchar "строка ПРеменной длины"
4) Глюк: 1) добавляем поле в таблицу 2) редактируем его - изменяем имя в таблице базы данных на имя существующего поля. Результат - показывает на этом поле в окне метаданных чушь.
5) В диалоге "Добавить поле" при выборе типа "Справочник" желательно заменить выпадающий список на выбор в дереве.
6) Не доступные для изменения пользователем справочники ("Перечисления")были бы желательны, хотя можно обойтись и правами.
7)Хорошо бы иметь в Метаданные.Справочники.Поля еще окошечко быстрого просмотра информации (без вызова диалога "Поле") наподобие окна SQL Assistant IBExpert-а.
8) ИМХО, иконку для приложения надо сменить.
9) Как-то надо разрулить со значением по-умолчанию поля справочника (непосредственно в Метаданные). В том числе и для типа TReference
10) Странно, добавление 1000 элементов в справочник из скрипта заняло довольно много времени на глаз... Замер и скрипт приведу ниже.
11) В дереве Метаданные.База хочу иметь возможность сортировки не только по наименованию, но и по типу (система/конфигурация + наименование)
12) При подборе из справочника, ИМХО, лучше выбирать на двойной щелчек, а редактирование - по нажатию кнопки. Сейчас - наоборот
13) В деревьях хочется, чтобы элемент выбирался и по правому клику мыши. Сейчас приходиться выделить левым кликом, потом правым - открыть контекстное меню
14) Сложно сказать как, но удалось создать ситуацию, когда показывался только один регистр учета, а было несколько (их свойства можно было просмотреть).Пришлось воспользоваться правкой таблицы ACC
15) Хотелось бы выпадающего списка с историей файлов архива в Инструменты.АрхивацияБазы
16) Для того, чтобы можно было работать с несколькими Allegro одновременно, и различать их, хотелось бы в названии приложения на панели задач видеть имя базы.
17) В базе TechnoTrade при играх с подбором товара в документе поступления удалось повесить Allegro (может, и не повесилось, но через две минуты я его снял; были запущены два экземпляра приложения), повторить - не удалось :-(
18) В "О программе" хочу видеть номер билда
19) В контекстном меню Баланс на счете есть иконка (красненькая в дереве), а на регистре (синенькая в дереве) - нет.
20) Почему нельзя удалить Регистр из Баланса?
21) Хорошо бы скрывать в таблицах элемент с ID=0.
22) Многомерные Регистры хочу, про это уже говорили, но свое Хочу тоже выскажу.
23) Возможность добавлять описание объекта и атрибута метаданных. Весьма желательна возможность динамического создания справки для пользователя на основании этой информации средствами системы.
24) Невозможно уменьшить длину varchar поля. Можно было бы спросить, уверен ли я в своих действиях и сделать, что я хочу.
25) Без средств отладки скрипта (может я их не нашел) - не выстрелит.
26) историю реквизитов системно делать не надо, ИМХО. Я их легко сделал тем что есть.
27) Документация и еще раз документация.
← →
MMF © (2004-04-19 12:51) [283]Ап. Что, народ полностью потерял интерес к сабжу?
← →
kaif © (2004-04-19 14:29) [284]2 Anatoly Podgoretsky © (19.04.04 09:39) [281]
Я придаю большое значение документации и пишу ее. Просто объем слишком велик - не успеваю.
2 MMF © (19.04.04 12:51) [283]
Форума пока нет (работаем над этим). Баг-репорты можно отправлять на E-Mail (Контакты). Там есть мой адрес:
ashot@gaapinvest.com
Спасибо за великолепный список найденных ошибок и недоработок!
Это именно тот формат, который сейчас в наибольшей степени позволит устранить множество недостатков. Согласен почти со всем и почти все понял.
С пошаговой отладкой пока придется подождать. Однако потребность в ней возникает в основном из-за отсутствия описания языка. Я должен еще разобраться с лицензиями - не все описания я могу публиковать на своем сайте - часть вынужден дать в виде ссылок на соответствующие сайты производителей. А так как сайт еще не готов, с этим тоже вылезают проблемы. Описание языка Delphi Script и всех ограничений можно скачать с сайта производителя:
http://www.dream-com.com/downloaddocs.html#DreamDocs
Важные ошибки и недоработки:
Ошибка с зацикливанием приложения Allegro.exe (которую Вам удалось воспроизвести в конфигурации TechnoTrade) уже несколько дней, как выявлена и устранена. Она возникала при перемещении экранного карета в конец строки в сетке "с поиском по нажатию" при помощи многократного нажатия "стрелки вправо". Связана была с неправильной работой функции StatusBarDisplay. Вы можете пока закомментировать вызов этой функции в скрипте при поиске "по нажатию" (событие SetEditText сетки).
Добавление 1000 элементов в справочник может занять значительное время, если пытаться делать это стандартными средствами. Видимо, мне нужно реализовать еще и массовую вставку. Дело в том, что стандартная вставка элемента в справочник (она предназначена только для ручного ввода данных) происходит так:старт отдельной транзакции (доступа к ней нет)
вставка строки в базовый класс (e.g. Товары)
вставка строки в дочерний класс (e.g. Компьютерные комплектующие)
вставка строки в дочерний класс (e.g. Мониторы)
вызов процедуры <имя класса>_SET_NAMES
подтверждение транзакции.
Очевидно - это самый длинный путь. Во-первых неоправдан постоянный старт и коммит транзакции. Во-вторых процедура форматирования наименовний - тоже вещь не быстрая, если ее вызывать для каждого элемента справочника отдельно.
Для массовой вставки нужна несколько другая логика. Нужно стартовать транзакцию, вставить нужные строки в таблицы, затем вызвать процедуру форматирования сразу для всего справочника и затем подтвердить транзакцию. Тогда это было бы быстрее.
Есть еще одно место: генерация справочных элементов в окне Метаданных. Там плохая реализация (если рандомайз повторяет значение - вставка не происходит, но это тормозит при больших объемах генерации - я потом исправлю).
И еще уточните, пожалуйста, что именно Вы пытаетесь сделать:(20) Почему нельзя удалить Регистр из Баланса?
Спасибо за подробные сообщения. Я проработаю их все в ближайшее время, что возможно исправлю и выставлю новую версию на сайт.
← →
kaif © (2004-04-19 16:05) [285]Итак, summary обсуждения:
1. Народ однозначно хочет многомерные регистры. Это отдельная большая тема, возможно нужна хорошая модель с возможностью обслуживания "критических ресурсов" типа "резервируем последний товар на складе". Быстродействующая, возможно с промежуточными итогами (пока не уверен)
2. "Исторические атрибуты". Тема пока неясная и скользкая. Нужно уточнить, что именно мы под этим имеем в виду: скрывать старые версии объектов или скрывать старые версии значений атрибутов и вообще, в чем главная причина того, чтобы такие данные оказываются в "Справочниках"?
3. ReadOnly справочники, возможно с интерфейсом типа ComboBox для очень мелких справочников (перечислений). Это однозначно нужно сделать (явное упущение).
4. "Иерархические справочники". Тема еще более скользкая и пока непонятная. Идет ли речь о древовидном способе отображения строгой линейной атрибутики или о гибких рубрикаторах, оставленных на полный откуп пользователю. Должны ли это быть рубрикаторы (тип поля в составе класса) или отдельно стоящие особенные справочники, существование которых мог бы конфигурирующий позволить или исключить по своему усмотрению.
5. Нужно доработать интерфейс справочника. Рад эргономических неувязок (интерпретация двойного щелчка), интерпретация пустых строк NOT NULL, возможно предварительная обработка строк (trim и др. функции), AutoSelect и так далее.
6. Сама учетная модель (баланс и его стиль) уже не вызывает негодования (как было несколько лет назад).
7. Система классов справочников - похоже, тоже.
← →
Anatoly Podgoretsky © (2004-04-19 16:16) [286]kaif © (19.04.04 14:29) [284]
Я не про время, а именно про профессиональные знания документо писания, это достаточно сложная отрасль знаний, разработчикам очень редко подвластная!
Разработчик хорошо знает систему, но написать правильно им редко удается. Вот для этого и существует профессия писатель документации по продукту.
← →
MMF © (2004-04-19 16:17) [287]Вставки были в одной транзакции. 64с на 1000 вставок в справочник третьего уровня (есть отец и дед).
Хотелось бы еще интерфейс к предопределенным событиям системы: ПриПодключенииПользователя, ПриНачалеРаботыСистемы, ПриЗавершениеРаботыСистемы, ПриХХХ.
Еще наблюдение: загрузка-выгрузка средствами Allegro - при открытии Документы.Проводник - исключение: BLR ... FORMAT_DATETIME . А до выгрузки все нормально было.
← →
Anatoly Podgoretsky © (2004-04-19 16:18) [288]Видишь как возрастает нужность в форуме и сопутсвующиз разделах, типа WishList, Future Plans и т.д.
Займись этим в срочном порядке, потом тяжелее будет.
← →
kaif © (2004-04-19 16:41) [289]2 MMF © (19.04.04 16:17) [287]
Вставки были в одной транзакции. 64с на 1000 вставок в справочник третьего уровня (есть отец и дед).
Что использовалось для вставок? Если компонент TRefQuery, то хотя он и подключен к Вашей транзакции, то это транзакция на чтение. Я же говорю о том, что сам компонент вызывает еще отдельную транзакцию (созает ее сам рантайм) на каждую вставку по той схеме, что я привел. Поэтому он не предназначен для массовых вставок.
при открытии Документы.Проводник - исключение: BLR ... FORMAT_DATETIME
А библиотека AllegroUdf установлена? Я не понял насчет загрузки/выгрузки... Уточните, пожалуйста, о чем идет речь?
Хотелось бы еще интерфейс к предопределенным событиям системы: ПриПодключенииПользователя, ПриНачалеРаботыСистемы, ПриЗавершениеРаботыСистемы, ПриХХХ.
У меня была такая вещь в Allegro, но потом я поддержку всех этих событий временно удалил. Хочу сделать этот механизм более стройным и удобным. Невозможно сделать как попало. Дело в том, что потом придется поддерживать старые версии конфигураций и этот механизм уже нельзя будет радикально изменять.
Anatoly Podgoretsky © (19.04.04 16:18) [288]
Видишь как возрастает нужность в форуме и сопутсвующиз разделах, типа WishList, Future Plans и т.д.
Займись этим в срочном порядке, потом тяжелее будет.
Да, я просто не ожидал такого бурного развития событий...
Уже занимаюсь.
← →
euru © (2004-04-19 16:49) [290]>kaif © (19.04.04 16:05) [285]
>4. "Иерархические справочники".
Добавлю свои 2 копейки.
Справочники должны быть линейны. Из назначение - хранить информацию. Навигационная информация, позволяющая по каким-либо критериям, находить эту информацию в справочнике должна храниться отдельно от самого справочника. Это позволит с одной стороны не перегружать справочник дополнительными атрибутами в случае ненадобности навигации, а с другой стороны появится возможность создавать несколько различных вариантов навигации.
← →
MMF © (2004-04-19 16:55) [291](kaif © 289) 1) использовал TIBSQL http://mmf.newmail.ru/TestAllegro.zip - только ногами особо не пинать, я не волшебник, а только учусь.
2) Установлена. До выполнения: Инструменты.Архивация и Инструменты.Восстановление базы из архива (в тот же файл), такого глюка не было, работали как демо-склад, так и эта. Каюсь, у меня FireBird 1.0.2.
← →
MMF © (2004-04-19 17:25) [292](kaif ©) Упс... А на RefQuery я внимание и не обратил, равно как и на всю панель Allegro :-(
← →
MMF © (2004-04-19 17:45) [293]Еще одно в WishList и для Up-а: нужна отработка сетками справочников (в документах работает) вращения колесика мышки.
(291+) Виноват. Сократил время добавления 1000 элементов до 19 секунд (в 3 раза). Тормозило обновление прогрессора:
procedure TfTestDataCreater.RefreshProgressBar(NewPos, Range: integer);
var BarPos: integer;
begin
BarPos:= round(NewPos / Range * ProgressBar1.Max);
if BarPos <> ProgressBar1.Position then
begin
ProgressBar1.Position:= BarPos;
ProgressBar1.Refresh;
end;
заменил на
BarPos:= round(NewPos / Range * FProgressBarMax);
if BarPos <> FProgressBarPosition then
begin
ProgressBar1.Position:= BarPos;
FProgressBarPosition:= BarPos;
где FProgressBarMax, FProgressBarPosition - члены класса формы.
← →
MMF © (2004-04-19 18:09) [294]Последнее на сегодня пожелание: нужен инструмент, создающий архив всех составляющих ИБ. Иду домой, хочу унести все: мне нужно не забыть взять все скрипты, а вдруг они не в одном каталоге. Удобно было бы одним нажатием получить и gbk и zip всех скриптов, использованных в ИБ. Удачи!
← →
kaif © (2004-04-19 20:39) [295]2 MMF © (19.04.04 16:55) [291]
Ни в коем случае не рекомендуется юзать версии Firebird ниже 1.5 RC4.
Возможны ошибки, особенно связанные с работой с метеданными и baclup/restore.
Сейчас посмотрю Ваш тестовый скрипт.
← →
kaif © (2004-04-20 04:54) [296]2 MMF © (19.04.04 11:11) [282]
Исправлены пункты 2,3,4,11,13,16,17 из Вашего списка ошибок и пожеланий. Войдут в ближайший апдейт. Пожалуйста, свяжитесь со мной по ICQ или E-mail. Совсем технические мелочи не будем здесь обсуждать.
Если есть еще вопросы у участников - задавайте. К сожалению, никто не прокомментировал идею gaapinvest, как формата совместных проектов (не считая первой негативной реакции).
Идея написания Allegro возникла еще в 2002 году и тогда здесь на форуме я пообещал, что сделаю эту систему и доложу здесь о результатах. Тогда мало кто верил, что вообще что-нибудь получится и были жаркие споры. Как видите, что-то получилось. Почему бы не пойти дальше? (начать пробовать создавать стандартные узкоспециализированные конфигурации). Просто в этом вопросе уже многое не только от меня зависит...
← →
kaif © (2004-04-27 04:07) [297]Выложена новая версия AllegroSetup.
Ряд ошибок исправлен. Усовершенствовано окно "Метаданные".
Режимом ReadOnly справочников можно теперь управлять, лишив каких-то юзеров или роли привилегии на редактирование справочников в Инструменты/Привилегии пользователей.
Двойной щелчок в диалогах теперь работает как OK.
Новая версия ядра базы 5. Апдейт старых баз (3->5) автоматический при соединении (с принудительным backup).
Страницы: 1 2 3 4 5 6 7 8 вся ветка
Форум: "Потрепаться";
Текущий архив: 2004.05.16;
Скачать: [xml.tar.bz2];
Память: 1.85 MB
Время: 0.047 c
