Кассовые операции

В конце операционного  дня наличные деньги, выданные клиентам, списываются:

Дт р/счет клиента (40702)

Кт касса кредитных  организаций (20202)

 

1.5 Ревизия кассы.

 

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

После издания приказа о назначении кассира, руководитель предприятия обязан под расписку ознакомить его с Порядком ведения кассовых операций в Российской Федерации. После этого с ним заключается договор о полной материальной ответственности.

В сроки, установленные письменным распоряжением руководителя предприятия, а также при смене кассира производится внезапная ревизия  кассы с полным полистным пересчетом денежных знаков и проверкой других  ценностей, находящихся в кассе.

Инвентаризация кассы проводится комиссией, назначаемой приказом (решением, постановлением, распоряжением) руководителя. Комиссия проверяет достоверность данных бухгалтерского учета и фактического наличия в кассе денег, разных ценностей и документов путем полного пересчета. Результаты инвентаризации оформляются актом в двух экземплярах и подписываются  всеми членами комиссии и лицами, ответственными за сохранность  ценностей, и доводятся до  сведения руководителя. Один экземпляр акта передается в бухгалтерию организации, второй – остается у материально ответственного лица.

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

 

Дебет  50 «Касса организации»

Кредит 91 субсчет «Прочие доходы»

- отражен  в  составе   внереализованных  доходов излишек денежных средств в кассе

При обнаружении недостачи производится запись  по дебету счета

«Недостачи и потери от порчи  ценностей».

Дебет 94

Кредит 50 субсчет «Касса организации»

- учтена недостача денег в кассе

Потом в бухгалтерском  учете  эти  суммы  списываются  на  материально ответственное лицо.

Дебет 73 субсчет «Расчеты по возмещению материального ущерба»

Кредит  94

- отнесена сумма  недостачи   за  счет  виновного лица

Выполнение предприятиями всех требований Порядка ведения кассовых операций контролируют банки, в которых обслуживаются предприятия.

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

2.1 Обследование предметной области

 

При создании банка основной его задачей является получение  прибыли. Но для успешного функционирования банка необходимо соблюдать ряд определенных условий, от них напрямую зависит то как будет работать банк, его прибыль и убытки, а так же возможность его дальнейшего расширения и предоставления клиентам новых услуг. В связи с тем что направления работы банка осуществляются с учетом анализа рисков, возможной прибыли и потерь. Возникает необходимость в введение учета кассовых операций, и возможность оперативного анализа полученных доходов и их дальнейшее распределение по усмотрению аналитического отдела. Создание программного продукта, который удовлетворяет ряду требований предъявляемых для автоматизации учета кассовых операций, является одной из главных задач, которыми должен заняться отдел по техническому и программному обеспечению банка.

Программный продукт, разработанный  в рамках данного курсового проекта, является наиболее подходящим для автоматизации учета кассовых операций коммерческого банка.

Источником поступления  данных являются сведения о клиентах банка и суммах вносимых ими в кассу или получаемых из кассы.

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

        Итак, по данной предметной области была разработана локальная реляционная база данных "Кассовые операции", решающая задачи автоматизации учета кассовых операций коммерческого банка.

Основные возможности  спроектированной базы данных:

- защита от несанкционированного доступа;

- ввод и хранение информации о кассовых операциях банка;

  - модификация, а так же вывод интересующей информации на экран и печать.

 

2.2 Концептуальное проектирование

 

2.2.1 Перечень сущностей

 

Сущность (объектное множество, таблица) – это собирательное понятие, абстракция реально существующего процесса, объекта или явления, о котором необходимо хранить информацию.

В данном курсовом проекте, чтобы не допустить  избыточность данных были спроектированы следующие сущности в соответствии с определенными входными данными:

1. Сущность «банк» хранит информацию о банке;

2. Сущность «учетные записи» содержит информацию об учетных записях пользователей и паролях;

3. Сущность «ревизия» заключение ревизии кассы;

4. Сущность «операция_имя» наименование кассовых операций;

5. Сущность «операции» содержит информацию о произведенных операциях;

6. Сущность «счет» содержит номера счетов клиентов банка;

7. Сущность «клиент_ю» содержит информацию о клиентах банка, являющихся юридическими лицами;

8. Сущность «клиент_ф»  содержит информацию о клиентах банка, являющихся физическими лицами;

9. Сущность «тип_к» содержит наименования типов клиентов.

 

 

 

2.2.2 Перечень атрибутов

 

Атрибут (реквизит) – поименованная характеристика сущности.

В результате изучения предметной области и проектирования базы данных, был составлен следующий список атрибутов:

1. Сущность «банк»

• наименование
• банк
• бик
• ИНН
• кор_счет

2. Сущность «учетные_записи»

• имя
• пароль
• права

3. Сущность «ревизия»

• код
• дата
• сумма
• операция
• обстоятельства

4. Сущность «операция_имя»

• операция
• наименование

5. Сущность «операции»

• код
• дата
• сумма
• счет
• операция
• банк

6. Сущность «счет»

• счет
• клиент
• дата

7. Сущность «клиент_ю»

• Клиент
• Наименование
• Адрес_ф
• Адрес_ю
• Телефон
• Код_типа

8. Сущность «клиент_ф» 

• Клиент
• фамилия
• имя
• отчество
• серия
• номер
• адрес
• Телефон
• Код_типа

9. Сущность «тип_к»

• Код_типа
• наименование

 

 

 

2.3 Инфологическое проектирование  базы данных

 

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

Цель инфологического  моделирования – обеспечение  наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Поэтому инфологическую модель данных пытаются строить по аналогии с естественным языком (последний не может быть использован в чистом виде из-за сложности компьютерной обработки текстов и неоднозначности любого естественного языка). Основными конструктивными элементами инфологических моделей являются сущности, связи между ними и их свойства (атрибуты).

 Связь – ассоциирование двух или более сущностей. Если бы назначением базы данных было только хранение отдельных, не связанных между собой данных, то ее структура могла бы быть очень простой. Однако одно из основных требований к организации базы данных – это обеспечение возможности отыскания одних сущностей по значениям других, для чего необходимо установить между ними определенные связи. А так как в реальных базах данных нередко содержатся сотни или даже тысячи сущностей, то теоретически между ними может быть установлено более миллиона связей. Наличие такого множества связей и определяет сложность инфологических моделей.

В базе данных «кассовые операции» определены  следующие отношения между таблицами:

 

 

Таблица «операция_имя»   Таблица «операции»

операция       операция 

Тип отношения: один ко многим;

 

Таблица «операция_имя»   Таблица «ревизия»

операция      операция 

Тип отношения: один ко многим;

 

Таблица «счет»     Таблица «операции»

счет       счет 

Тип отношения: один ко многим;

 

Таблица «клиент_ю»    Таблица «счет»

Инд       операция 

Тип отношения: один ко многим;

 

Таблица «клиент_ф»    Таблица «счет»

инд        год

Тип отношения: один ко многим;

 

Таблица «тип_к»    Таблица «клиент_ю»

Код_типа      Код_типа 

Тип отношения: один ко многим;

 

Таблица «тип_к»    Таблица «клиент_ф»

Код_типа       Код_типа

Тип отношения: один ко многим.

 

 

 

2.4 Реляционная модель БД

 

Реляционная модель данных была предложена Е. Коддом, известным американским специалистом в области баз данных. Эта модель позволила решить одну из важнейших задач в управлении базами данных – обеспечить независимость представления и описания данных от прикладных программ.

В структурной части  модели фиксируется, что единственной структурой данных, используемой в  реляционных БД, является нормализованное n-арное отношение. В манипуляционной части модели утверждаются два фундаментальных механизма манипулирования реляционными БД - реляционная алгебра и реляционное исчисление. Первый механизм базируется в основном на классической теории множеств (с некоторыми уточнениями), а второй - на классическом логическом аппарате исчисления предикатов первого порядка.

 

 

2.4.1  Функциональные зависимости между атрибутами

 

В разработанной базе данных существуют следующие функциональные зависимости между атрибутами:

 

Таблица 1 – банк

Наименование атрибутов	Функциональные зависимости
Банк
Наименование
ИНН
Кор_счет
БИК

 

 

Таблица 2 – учетные записи

Наименование атрибутов	Функциональные зависимости
имя пароль права