mazzy
Ей богу, чертовски неинтересно одно и то же повторять.
Может о функционале поговорим?

Вообще мысль здравая, только где? Здесь?.. Хотя скорее всего такого специализированного форума нигде и нету. Я так понял что mazzy хочет поговорить о функциональности с т.з. технического специалиста, а не главбуха?
mazzy
Например, я бы очень хотел поговорить о том, как выставлять fill rate для таблиц из разных групп.

Объясните чайнику, what's the Russian for fill rate в данном контексте?..
mazzy
Я бы очень хотел узнать как народ работает задним числом и позволяет ли изменять информацию в уже проведенных документах.

В систему (имхо :) обязательно следует закладывать такую функциональность, однако разрешать ее (вообще, или некоторым ответственным пользователям) исходя из используемого бизнес-процесса.
Я однажды наблюдал как в коммерческом банке с достаточно хорошо регламентированным бизнес-процессом оставили упомянутые права только главбуху (ну из головного управления, что ли, указивку спустили, или версия ОДБ обновилась - не упомню). Так через неделю права главбуха были выданы всем операционисткам. А то они работать не могли. Такая вот объективная реальность.
В нынешней же реальности куда проще бывает изменить документ, получив гневное официальное письмо от покупателя (которому неверно что-то написали или выписали и т.д. и т.п.), чем сторнировать и т.д.
Можно заменить выданный счет-фактуру, но спросите своего бухгалтера, захочет ли он заводиться с возвратом товара.
А вообще не говорите мне как надо, все определяется финансовыми результатами. Если дешевле сторнировать - значит, надо сторнировать. Вот и все. Тут даже социальных аспектов не наблюдается никаких.
Кроме того, в системе где принципиально нет изменения задним числом, рано или поздно появится необходимость в таковом. Из практики сужу :))
mazzy
Я бы очень хотел узнать мнение участников этого форума по поводу того, должны ли в erp-системе быть "регламентные процедуры"

Какой бизнес, такие и процедуры. Если есть выполняемые по расписанию операции (ср. капитализация счетов в банке), значит, есть поле деятельности для любителей автоматизировать создание документов.
А пересчет валютных остатков вы как выполняете?..
Или я не понял и Вы говорите об обслуживании БД?
mazzy
Я бы очень хотел узнать как народ работает с кредитными лимитами, вычисляются ли они на-лету или в регламентых процедурах. То же самое про себестоимость.

В частности, в оптовой торговле это (лимиты) трудно формализуемая вещь. Зачастую допустимая величина товарного кредита в ИС только хранится, а устанавливается в ходе переговоров с клиентом.
Расчетов себестоимости "на лету" ни разу еще не видел (но где-то, наверное, оно есть :) Например, в случае с импортными поставками товара полная себестоимость партии зачастую выясняется много позже того как товар уже продан. При определении цены приходится пользоваться как ориентировочными расчетами, так и уровнем цен конкурентов и другими отфонарными соображениями.
mazzy
Очень интересно до какого уровня доходит автоматизация, например, производства - До цеха, участка, станка, инструмента. И должна ли ERP-система включать в себя АСУТП...

А как Вы думаете, есть ли тут некие отношения подчиненности (ну вроде как в случае когда предприятие использует навернутую систему управления, ну или систему складской логистики, и формирует небольшие сводные отчеты, отправляя их "наверх" в холдинг в R/3 или что-нибудь подобное)? Ведь АСУТП может и посложнее быть на порядки, и критичнее - вплоть до работы в РВ.
mazzy
Я бы с удовольствием послушал о репликации и об организации работы удаленных филиалов...

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

Таки спрашивайте.
mazzy
Ну сколько можно перетирать на уровне "Майкрософт маздай"?
Пока не случится этот самый mustdie.

Dogen mazzy
Например, я бы очень хотел поговорить о том, как выставлять fill rate для таблиц из разных групп.
Хм... Общибся. Лучше было сказать fill factor.
Например, вот такая ссылка
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/createdb/cm_8_des_05_9ak5.asp

Могу только выдвинуть тезис, что все зависит от прогнозируемого объема таблицы, размера записи, темпов роста и т.п.
Ну так это же большие разницы в конкретных случАях. Список контрагентов может быть 10000 записей, а может 10 млн. То же касается товарного ассортимента.
Кстати, если индекс (и данные?..) умещаются в RAM, то стоит ли еще подобный вопрос на повестке дня (большинство вспомогательных справочников имеют пренебрежимо малый размер, isn't it)? И стоит ли он вообще для таблиц документов в OLTP, например? Они ведь такого размера, что речь пойдет скорее о размере индекса в целом (влияет на потребный объем RAM), и о планировании размера потребного дискового пространства (вот сейчас моя понимать почему грамотная человека всегда ругай MS SQL за фиксированный размер страницы). Что-то мне говорит что Вы занимаетесь чем-то из области учета (не ГИС, не CAD/CAM, не биллинг...)? Или я ошибаюсь?

Dogen mazzy
Я бы очень хотел узнать как народ работает задним числом и позволяет ли изменять информацию в уже проведенных документах.

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


Если бы я был бухгалтером, я бы мог с большей ответственностью говорить о том, насколько обосновано в реальной практике исправление первичных документов. Но в данной ветке я пы предложил принять за данность что так бывает. В единичных случаях.
Еще пример - выписали накладную на отпуск товара, а на складе оказалось что товар украли/разбили/и т.д. Частично. Что делать? Можно, конечно, удалить документ и создать новый. Не все будут рады такому бизнес-процессу.

mazzy
Dogen
В частности, в оптовой торговле это (лимиты) трудно формализуемая вещь. Зачастую допустимая величина товарного кредита в ИС только хранится, а устанавливается в ходе переговоров с клиентом.
Расчетов себестоимости "на лету" ни разу еще не видел (но где-то, наверное, оно есть :) Например, в случае с импортными поставками товара полная себестоимость партии зачастую выясняется много позже того как товар уже продан. При определении цены приходится пользоваться как ориентировочными расчетами, так и уровнем цен конкурентов и другими отфонарными соображениями.
В том, то и вопрос: почему это трудно формализуемая вещь? Почем не видел? А как же тогда работают интернет магазины типа amazon?

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

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

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

mazzy DogenТаки спрашивайте.
Таки да. :)
Для начала ограничим список вопросов теми, что прозвучали.

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

mazzy
можно и такие вопросы...
Счет-фактура - вообще странный документ.

По-правильному, есть два документа - накладная и... пусть будет invoice.
В накладной указывается только количество. Без цен и сумм.
В инвойсе указывается сумма, скидки, условия оплаты.

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

Что теперь имеем?
Теперь имеем два ОБЯЗАТЕЛЬНЫХ документа, которые полностью дублируют друг друга.
Темерь мы имеем совершенно дебильный документ Счет-фактура и книгу продаж, по которому даже НДС не проверишь с толком.

вот.
стало быть ответ: храним. А куда ж мы денемся то с подводной лодки?
...fattura invoice тогда что ли, чтоб не путали с proforma invoice.

А кстати. Если есть несколько товарных позиций и в каждой указана цена (я ведь могу с точностью до любого знака ее указать, например до третьего), то сумма количеств*цену может не равняться сумме документа. Что считать справочной величиной (т.к. я не уверен что может быть сумма документа "дробнее" чем копейка), и насколько правомерно тут округление?

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

mazzy DogenА почему бы не хранить электронный документ, в котором записано кто кому что передает, и не печатать из него и накладную, и счет-фактуру?
О-о-о. Это очередной длинный вопрос.
Начать надо с того, что... А почему вы решили, что печатать ОБА документа вы будете печатать с ОДНОГО электронного?
Ага. Ключевые слова "вы решили". Правильно, мы так решили в лохматые доисторические времена, причем особо не задумываясь (мы не потратили много усилий на проектирование того что тогда писали, а взяли набор функций у БЭСТ-4. В каком году появился счет-фактура, я не упомню, но как Вы писали, стандартное мнение было таково что от накладной он только внешним видом отличается). Думаю, что упрощение структуры данных дало больше чем гипотетическая возможность иметь разные даты и суммы накладных и счетов-фактур и т.п. Многие так поступают. Сейчас ситуация не то чтобы изменилась, но появилась возможность поразмышлять на эту тему.

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

mazzyВо-первых, дата накладной и дата счета-фактуры могут быть разными. Можно хранить в электронном документе дату счета-фактуры и номер счета-фактуры.

mazzyВо-вторых, счет-фактура может выписываться по нескольким накладным, и наоборот, одна накладная и несколько счетов-фактур.
А это уже более интересно. Многие были бы рады также возможности печатать сборные накладные, а именно несколько документов на отпуск товара на одной бумажной накладной (по крайней мере это часто может быть удобно для кладовщика, и т.д. и т.п.)

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

mazzyО-о-о. Это очередной длинный вопрос.
А вот еще.
1. Хранение всех версий записи в таблице (в моем практическом случае это увеличит объем данных в 1.3...3 раза, "но эту жертву я готов принести" - на крайняк всегда можно сбросить неактивные записи в архивную таблицу, имеющую ту же структуру). Версии связывать в список или в куст (ссылаться на первую или на предыдущую)? Назначение такого усложнения очевидно - получать распечатки в том же виде как они были год назад получены, а также с легкостью получать состояние любого документа в любой момент времени. Когда документы стоят по многу тысяч ежиков, становится не жалко ресурсов на организацию подобной системы. Ибо русский человек иногда туп, иногда хитер до невозможности. В обоих случаях примитивные логи полезны, но неудобны.
2. Типовые решения для структур данных партионного учета. Я хочу получить себестоимость товара (разнесенную по массе единиц товара) для всех товаров, находящихся в разных точках их маршрутов в системе логистики [поставок]. При этом можно считать отдельной товарной позицией сочетание товар+документ_в_котором_он_попал_в_систему (например, накладная на отпуск со склада поставщика), но по-моему тогда я смогу быстро получать только среднюю себестоимость (а партии товара могут переформировываться, например часть товара уже уехала с временного склада, а часть осталась, и по упомянутому ключу я смогу выбрать весь такой товар + накладные расходы на поставки, это слишком упрощает картину и не дает ответа на вопрос "сколько стоит весь товар, лежащий в конкретном месте"). Кто-нибудь вообще подобным занимался?
3. Резервирование товара. Или иметь отдельную таблицу заказов, или ввести стадии обработки документа (черновик, план, выписан, исполнен и т.п.). Что с вашей точки зрения полезнее/правильнее?

LSVСтадии обработки док-та АБСОЛЮТНО НЕОБХОДИМЫ !
Можно добавить такие стадии (для товара):
- Зарезервирован(отложен)
- На погрузке
- В пути
- Получение подтверждено

Для удобств можно у каждой стадии сделать признаки, например признак
что товар ещё на территории нашего центра ответственности.
На погрузке(это пока у нас), В пути (уже не у нас)
Я бы сказал, что есть маршрутная карта документа, и есть признаки, которые в общем случае необязательно соотвествуют точкам на маршруте. Не суть важно.
Вы перечисляете скорее стадии процесса исполнения документа. А я хотел сделать акцент на том этапе, когда документ существует в виде черновика, затем в виде заказа (в соответствии с которым резервируется товар и печатается proforma invoice, например), и только потом он (документ) выпускается, подписывается-пропечатывается и поступает на склад.

LSVАналогично нужно иметь стадии для финансовой составляющей поставки.
Введение дополнительной несложной аналитики позволяет получить буквально любую цифру (к-во по местам хр., резерв, сбс) из журнала перемещений.
Удобно, когда признаки древовидные. Тогда легко узнать цифру и по одному признаку и по группе/ветке признаков.Само собой. Я имею в виду несколько другое. Например.
Товар (100 шт. по цене EXW 1р./шт.) перевезен из пункта А в Б, за 10 рублей.
Себестоимость его составляет в моем понимании 110 рублей.
Затем часть товара (30 шт.) перевезли в пункт В за 5 рублей.
Итого в Б лежит 70 шт., себестоимость их 77 рублей.
В пункте В лежит 30 шт., себестоимость их 38 рублей.
Тут вопрос, можно ли изобрести настолько извращенную структуру данных, чтобы одним-двумя запросами получить данные о том, где лежит сколько чего и сколько стоит это "чего". Нужно это хотя бы для того чтобы обосновать цену товара при продаже его с временного склада (или посчитать стоимость украденного/испорченного).
Хранить какие-либо цены кроме EXW в документах нет возможности, т.к. таможенные документы, счета на услуги железной дороги и т.п. объективно невозможно иметь к началу продаж. То есть себестоимость товара на момент передачи его на другой склад может измениться спустя пару недель.

LSV Тут вопрос, можно ли изобрести настолько извращенную структуру данных, чтобы одним-двумя запросами получить данные о том, где лежит сколько чего и сколько стоит это "чего".
Все операции имеют соотв. знак. Внутперемещение создаёт две записи в журнал: СписаниеСоСклада1 -> ПриходованиеНаСклад2.
Полупроводками предлагаете делать? Впрочем, это здесь несущественно.
LSVПри изменении СБС правится СБС всех расходных операций, привязанных к этому приходу (согласно таблицы привязок).
Всё это работает отлично и быстро ! :) А главное крайне универсально ! :)

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

LSVСледует предусмотреть механизм непотери привязки приходной партии для внут.перемещений. Хотя тут могут появляться доп. затраты при перемещении/перевозке/перепаковке, которые следует учесть задним числом :(
Например рекурсия неизбежна при расчёте производства, когда товар превращается в другой товар, а тот в свою очень в другой товар... :(
Но зная уровень вложенности комплектов можно придумать процедуру, которая сначала считает товары с 0-вым уровнем вложенности, затем 1-м, 2-м и т.д. Знаю, что такой подход имеет некоторые ограничения ! Все подходы имеют свои ограничения, особенно расчёт сбс. :)
Но...пересчитывается это довольно быстро: 15сек/цикл на 2х3ГГц 2.5млн. строк в тов.жур.
Это все лежит на поверхности и довольно-таки некрасиво (исключая рекурсию).
А кто-нибудь вообще видал вразумительные описания различных методов расчета себестоимости? Кто-нибудь занимался не только себестоимостью поставок/производства (интересует производство, сходное с поставками/перевозками, т.е. расчет с/с отдельных изделий или партий) товара, но и логистикой продаж (мы, например, оказываем транспортные услуги нашим покупателям, но особенно не пытались анализировать данный процесс и его рентабельность)?

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

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