Просматривая на сайте KWORK заявки на разработку программного обеспечения, я нашел интересный запрос, по видимому от самозанятого или предпринимателя, у которого есть своё небольшое производство: нужна простая программа для анализа рентабельности производственного процесса, по сути – учет затрачиваемых материалов и сравнение с прибылью, получаемой от реализации готовой продукции. Конечно, для полного анализа необходимо также учитывать расходы на электроэнергию, аренду помещения, амортизацию оборудования, налоги и т.д., но в некоторых случаях достаточно контролировать только материалы и готовую продукцию.
Несмотря на большое количество программ учёта, в том числе бесплатных, люди ищут то, что подходит именно им. И когда таблички в MS Excell перестают их устраивать, а покупать 1C или платить ежемесячную мзду за онлайн сервисы они не готовы, то у разработчиков платформы My Visual Database появляется шанс предложить им оптимальное решение.
Теория
Когда речь заходит об учете прибыли, первым делом встаёт методика расчета себестоимости. Задача была бы тривиальная в случае, когда цена используемых материалов не меняется, а производство не имеет брака. Но в реальности всё сложней: цены закупки постоянно меняются, а технологии производства дают сбои, в результате которых часть сырья, а порой и готовой продукции, приходится списывать.
Для правильного расчета себестоимости в бухгалтерии применяют несколько методик расчета: FIFO, LIFO и партионный учёт. Последний лучше всего подходит для автоматизации учёта и даёт полную и четкую картину, так как основан на учете партий товара.
Партия товара – это товар определенной номенклатуры с определенной ценой закупки.
Традиционный бухгалтерский учёт подразумевает перемещение информации о стоимости и количестве между отдельными субсчетами – аналитическими единицами учёта. При этом каждый документ учета порождает множество отдельных бухгалтерских проводок. Но в нашем случае будет работать упрощенная система. Она будет включать учет первичной документации (приходные и расходные накладные), детализация которых и будет выступать в качестве проводок. В результате можно будет увидеть следующие экономические показатели:
- Остатки на складе
- Объемы производства
- Объемы закупок/продаж
- Прибыль/убыток
По сути учет производства отличается от учёта продаж наличием специального контрагента, который получает со склада материалы, а возвращает готовые изделия. В дальнейшем этого контрагента будем величать “производственный участок” или “цех”. Для удобства создания производственных документов имеется специальный справочник, в котором описаны нормативы расхода материалов, необходимых для создания того или иного изделия.
Схема данных
Обозначим перечень сущностей, необходимых для реализации проекта.
- Тип номенклатуры –itemType
- Номенклатура – item
- Комплектующие – productItem
- Партия материала/товара – pItem
- Тип контрагента – contrType
- Контрагент – contr
- Тип документа – docType
- Документ – operDoc
- Бухгалтерская операция (детализация документа) – oper
Справочники docType и contrType являются служебными – в этих таблицах значение поля ID используется в логике работы программы. Поэтому они заполняются автоматически при первом запуске приложения и не редактируются. Остальные таблицы являются пользовательскими и для каждой из них имеется форма табличного представления и форма редактирования. Рассмотрим их подробней.
itemType
Тип номенклатуры добавлен для двух целей:
- Разделить материалы (isProduct = 0) и готовую продукцию (isProduct = 1)
- Фильтровать и группировать номенклатуру для удобства поиска и анализа
item
Номенклатура относится к определенному типу (id_itemType), имеет обязательное название (name) и необязательный артикул (code)
productItem
Состав продукции – это перечень номенклатурных единиц (id_item1), которые входят в состав данной продукции (id_item) с указанием количества (qty). Данный справочник не является обязательным, но помогает создавать документы для списания материалов на производство – он как содержит нормативные требования и облегчает планирование производства. Его можно использовать для оценки материальных запасов на предмет количества продукции, которое можно из них произвести. Но планирование производства – это отдельная тема, которая в данном проекте раскрываться не будет.
pItem
Партия позволяет объединять различные действия в единый процесс. Это звучит как политический лозунг, то на самом деле это способ облегчить формирование SQL-запроса для осуществления некоторых действий: определение цены закупки/производства, контроль остатков, подсчет прибыли/убытка.
Пока у партии нет своего визуального идентификатора, только ссылка на номенклатуру (id_item), но скорей всего в дальнейшем для удобства будет добавлено вычисляемое поле для отображения названия партии, которое будет состоять из названия номенклатуры и порядкового номера (в хронологическом порядке прихода).
operDoc
Документ включает традиционные обязательные поля: тип документа (id_docType), дата (docDate), номер (docNum), откуда (id_contr) и куда (id_contr1) движутся материалы или товар. Также имеется необязательное поле для комментария (comment).
oper
Детализация документа (бухгалтерская операция) содержит связь с документом (id_operDoc), ссылку на партию (pItem), а также сведения о количестве (qty) и сумме (amount). При необходимости сведения о цене будут вычисляться по формуле: <Цена> = <Сумма> / <Количество>
contr
Контрагентом могут быть поставщики, покупатели, а также склады и производственные цеха предприятия. Контрагентов может быть много (если требуется аналитика по разным контрагентам), а может быть по одному каждого типа (id_contrType). Так как программа служит только для учета производства, то у контрагентов только одно поле с реквизитами – название (name).
Используем наработки
Ранее в нескольких статьях разбирались различные технические приёмы, которые хотелось бы использовать и в других проектах, в частности в данной программе. Для этого я скопирую все папки проекта ClassExplorer, кроме папки Extras, в папку проекта Production. После чего создам в Notepad++ папку нового проекта и наполню его файлами из скопированных папок. Для этого используем пункт всплывающего меню “Добавить файлы из директории..”
После чего выполнить последовательно следующие действия
Удалить из проекта:
- script.dcu
- script.pas
Удалить из проекта и папок на диске:
- Все файлы в папке Forms, кроме Forms.pas и Main.pas
- Вложенные папки в папке Tools, кроме DBG (отладчик)
Откорректировать файлы, приведя в соответствие секции uses, перечни переменных и констант, а также удалив ненужные процедуры и функции:
- ConstVar.pas
- UserApp.pas
- Forms\Forms.pas
- Forms\Main.pas
- Tools\Tools.pas
На самом деле чистка кода оказалась кропотливым и долгим занятием, а всё потому, что компилятор в режиме использования модулей в некоторых случаях не может точно показать место, в котором находится ошибка. Это один из главных недостатков использования модулей, который может свести с ума. Поэтому я буду перекраивать модули до тех пор, пока не выработается простая, чёткая и ясная последовательность действий, позволяющая переносить скрипты из одного проекта в другой.
После обновления сведений о названии проекта и его версии, я заменил файлы логотипов на более подходящие по тематике. В результате программа-заготовка готова для наращивания функциональности.
Продолжение следует.