В поисках идеальной ERP системы 3.0

Продолжение одновременно нескольких тем:

Если бы я попытался воспроизвести функциональность модуля «Управление Запасами» iScala, что бы я усовершенствовал?

В поисках идеальной ERP системы 2.1

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

Я с некоторыми коллегами уже обсуждал мои мысли, поэтому буду заимствовать записи из переписки и добавлять то, что пока хранится только на бумаге:

1. На обсуждение принципиальный вопрос: не хочется делать проводки, как в Скале, т.е. дебет — это положительная сумма, кредит — отрицательная, я за 30 лет столько натерпелся из-за этого. Думаю, что вполне уместно делать в каждой строке двойную запись: ДТ, КТ, сумма (ну и куча всяких других полей, это потом обсудим). При этом под Дебетом подразумевается либо учётная строка, либо набор отдельных полей, аналогично для Кредита. То есть в случае с набором полей в строке проводки проводки будет 20 учётных полей — 10 для дебета и 10 для кредита. Обсуждал количество учётных измерений с несколькими коллегами, они считают, что кроме счёта достаточно 5 учётных измерений, 9 (как в Скале) — избыточное количество
2. Преимущества использования двойной записи вместо отдельных строк (как в Скале)
   2.1. Это понятно для всех бухгалтеров, а не узкого круга тех, кто работал со Скалой
   2.2. Это даёт возможность строить отчёты по корреспонденции счетов (шахматки) без каких-либо дополнительных «приседаний» типа полуручного разнесения в RGW или убогих «приблуд» в виде bilinear инструментов.
   2.3. Это классическое представление, в конце концов
   2.4. Не нужно никаких флагов «проводка красное сторно»
   2.5. В модулях «Управление Запасами» и «Заработная плата» в Скале все проводки и так «бинарные» (один дебет, один кредит)
   2.6. При грамотном построении автоучёта это реализуемо без особых трудностей
   2.7. Это даёт возможность выгружать проводки в российские системы учёта. И, в то же время, возможно их группировать по счетам Дт и Кт и выдавать, как в Скале. А наоборот (из Скалы в вид Дт-Кт) часто это сделать невозможно
3. Как хотелось бы организовать продажи в новой ERP:
   Отказаться от подхода к счетам-фактурам «как в Скале». Имеется ввиду таблица SL03, где только итоги по счёту-фактуре и нет никаких подробностей. Взамен я предлагаю подход как с заказами на продажу и разными типами СФ.
   Информация предположительно должна храниться в 3-х таблицах (аналоги по подходу, но не обязательно по набору полей — OR20, OR21, OR23):
   Заголовок счёта-фактуры — автосчётчик (номер строки в таблице)!!!, покупатель, номер заказа/предложения/счёта на оплату, номер СФ, Сумма, сумма НДС, оплаченная сумма, учетная строка и т.д.
   Строки СФ — автосчётчик (номер строки в таблице)!!!, номер заказа/предложения/счёта на оплату, номер СФ, номер строки, код запаса, описание, количество заказанное, количество отгруженное, количество отфактурованное, код НДС, ставка НДС, сумма НДС по строке, код склада, код автоучета запаса, код автоучёта покупателя, Дата заказа, дата поставки, дата СФ, номер накладной, флаги. Посмотреть внимательно структуру XML файла строк СФ в Диадоке
   Строки поставки — автосчётчик (номер строки в таблице)!!!, номер заказа/предложения/счёта на оплату, номер СФ, номер строки, номер строки отгрузки, ID партии, кол-во распределённое по партии, кол-во отгруженное по партии, и т.п. + ссылка на строку в таблице аналитических проводок по запасам (аналог SC07)!!!
   При создании проводки по СФ (в Скале это журнал СФ SL04) обязательна ссылка на номер строки в таблице строк СФ, а при создании аналитической проводки по запасам — перекрёстные ссылки на номера строк в таблице строки поставок по СФ и номера соответствующих строк в таблице аналитических проводок по запасам!!! В Скале этого нет и это очень большая проблема!
   Мысль понятна?
4. Возможно, стоит все журналы созданных, но ещё не отправленных в Главную Книгу проводок объединить вместе в одной таблице, а не в разных, добавив только отдельное поле типа «код журнала» и туда записать что-то типа номера таблицы из Скалы, например, GL07, SL04, SL05, PA17, PL04, PL05, SC25. Это позволит быстро и удобно подсчитать баланс с учётом нового параметра «включая созданные, но не отправленные в ГК проводки?»
5. Мысли вслух про то, что в Скале называется «критерии выборки»: обычно в качестве критериев попадания в отчёт используются интервалы счетов (от и до), учетных измерений, кодов покупателей/поставщиков, типов проводок, диапазоны кодов складов и т.п. Это часто было проблемой, так как, например, нужно было включить в отчет склады, начинающиеся на 01 и на 90, а на 81, например, не включать. Очень замудренный механизм делать не хотелось бы, но, возможно, стоит предусмотреть задание по маске, например, склады *0??00. Или предусмотреть многозначные параметры, когда из списка выбираются несколько нужных значений. Ну, или значения перечисляются через запятую, в том числе, с указанием маски, например, склады 01*, 03*, 09*
   Или предусмотреть исключения, например, диапазон складов с 01 по 99, кроме диапазона с 80 по 899999
6. Может быть в проводках расхода (по запасам) указывать цену средневзвешенную и FIFO в двух разных полях?
7. В таблицу аналитических складских проводок обязательно добавить не только номер заказа, но и номер строки заказа и номер строки поставки + номер СФ. Отсюда вытекает, что СФ всегда соответствует поставленным строкам на момент распечатки/закрытия?
8. Если делать таблицу автоучёта по запасам по аналогии со Скалой, то всё равно убрать из неё Intermediate Account -> переместить это в параметры модуля.
   Также убрать оттуда Stock Receipt и Stock Issue. Во-первых, это всегда должен быть один и тот же счёт (пора забыть этот хитрый приём 30-летней давности, когда были ДТ счета и КТ счета), а, во-вторых, это не должно зависеть от комбинаций кодов, только от учётного кода 1, привязанного к запасу, поэтому счёт брать из списка учётных кодов, где будет не просто AccCode1, описание, но и счёт запасов. Соответственно, список учётных кодов по запасам должен стать годозависимым и копироваться при открытии нового финансового года процедурой копирования параметров из предыдущего (или любого другого выбранного) финансового года
9. Всё-таки сделать в карточке склада поля бухгалтерского счёта и УИ, только не 2 набора, как в Скале (IN и OUT), а один, который будет ДТ при приходе и КТ при расходе
10. Сделать таблицу типа проводок по запасам с описанием их типов, например, PUR, SAL, TAK, REV, COS, MOV и т.п. Эти типы проводок сделать настраиваемыми с точки зрения автоучёта, например, для типа PUR указать, что корреспондирующий счёт (счету запасов из списка учётных кодов, см. выше) берётся из таблицы автоучёта из столбца Accrued Receipt, а для проводки SAL — из поля Accrued Issue. Для MOV ничего не настраивается — всегда Intermediate Account. Для TAK (Stock Taking — инвентаризационная разница) — при отрицательной сумме из Stock Taking Shortage, при положительной — из Stock Taking Surpluss. А может быть создать 2 отдельных типа проводок вместо одной — Недостача при инвентаризации и Излишки при инвентаризации, так будет прозрачней для пользователя

Продолжение: В поисках идеальной ERP системы 3.01