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

← →
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 © (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-баланс неверно показывает финансовое положение фирмы, работающей в основном с одними и теми же контрагентами, но по куче договоров, каждый из которых имеет изолированные экономические отношения (без автоматических встречных зачетов даже в рамках одного контрагента). Об адекватности МИНФИНовского баланса в такой ситуации я вообще молчу. Есть ряд оснований предполагать, что в современном мире постепенно субъектом экономических отношений перестает выступать конкретная фирма и вместо нее таким субъектом становится "проект" или "договор". В конце концов, фирма это тоже всего лишь договор собственников и текущий баланс к нему. Поэтому я не исключаю возможности пересмотра многих даже классических положений в ближайшие годы, особенно в связи с быстрым развитием средств коммуникации, когда одну задачу решают множество фирм одновременно в рамках одного "проекта".

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

2 Anatoly Podgoretsky © (18.04.04 17:24) [269]
Я очень хочу приделать форум. Вы думаете, народ будет посещать? Я боюсь мертвого форума... Хотя если там обсуждать не только Allegro, но и сами принципиальные проблемы и все, что с этим связано, но, может, и будет какая-то жизнь... У меня нет опыта в создании форумов. В чем главный секрет? И главная пробюлема?

2 Anatoly Podgoretsky © (18.04.04 17:24) [269]
Мне неловко, что я сейчас нагружаю форум Мастеров. Конечно правильнее сделать свой.

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

А примеры есть, например форум Франсуа Пьетте, по объему сообщений и по их качеству могут многие только позавидовать. Это автор таких продуктов как ICS Internet Connection Suite и Midware

Просто такой сложный продукт обязан иметь форум, в каком виде - или почтовая рассылка или веб форум или группа новостей.
Удачно если будет одновременно рассылка и веб форум, для этого можно организовать группу на groups.yahoo.com уже готовый интерфейс.

kaif © (18.04.04 17:33) [271]
Та он уже перерос обычное обсуждение.
Структура форума уже становится неудобной для такого объема да и требуется рахбиение по темам, и уж молчу про персональную поддержку при проблемах с продуктом.

2 Anatoly Podgoretsky © (18.04.04 17:34) [272]
Спасибо за информацию. Правда половины слов я не понял... Ну да ладно, разберусь.

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

Ну я же тебе предложил воспользоваться http://groups.yahoo.com или ты обязательно хочешь именно на своем сайте, но это не обязательно, пускаq за тебя работают специалисты. Там размещено много shareware rus форумов, под базовым названием SWRUS

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?

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

>А как же вызов элемента на редактирование? Возможно, нужно >сделать наоборот - кнопка вызывает на редактирование, а >двойной щелчок - выбирает элемент.

Если есть отдельный режим редактирования справочника, то там конечно двойной щелчек будет вызовом строки на редактирование. По если это список, предоставленый для выбора по логике однозначно ожидается, что при двойном щелчке произойдет выбор.
И еще. Вполне логично, когда после выбора счета, имеющего справочник этот справочник откроется автоматом.

>>и не совсем ожидаемое поведение полей ввода чисел.
>Уточните. В чем проблема?

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

(kaif) скачал и попробовал написать маленькую конфигурацию. Появились вопросы и пожелания. У Вас есть форум, + багрепорты куда?

(279+) где можно почитать по ограничениям языка? Столкнулся с кучей ограничений (try except On e:Exception; типизированные константы не поддерживаются, проверка if Acomp is TControl не пашет, RTTI не работает, при запуске под дизайнером "if (AComp.Parent= tabReferences) and (AComp<>Sender) then" работает, а в самой системе - Parent не известен) и т.д. Хотелось бы познакомиться с полным описание чего можно/нельзя. Очень может быть, что я туплю, но ненашел как отлаживать скрипт?

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