Склад и валюты

← →
kaif (2003-09-30 07:58) [0]

Те, кто занимается автоматизацией реального склада, наверняка сталкивается с ситуацией, когда счета разных контрагентов ведутся в разных валютах (USD, EURO, RUB), а товары на складе учитываются в какой-то одной валюте, например, USD. Или даже товары тоже учитываются в разных валютах... Кто из разработчиков как подходил к этой проблеме? К какому подходу склоняются сами заказчики программ в конечном итоге? Меня интересуют самые разные мнения.

← →
LordOfSilence (2003-09-30 08:33) [1]

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

← →
Кулюкин Олег (2003-09-30 08:50) [2]

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

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

← →
Sergey13 (2003-09-30 09:21) [3]

http://talk.mail.ru/discussion.html?target=27029283&page=1
Обсуждение похожей темы.

← →
stone (2003-09-30 09:23) [4]

Таблица кросс-курсов валют.

← →
panov (2003-09-30 11:51) [5]

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

← →
kaif (2003-09-30 12:08) [6]

2 Sergey13 © (30.09.03 09:21) [3]
Я посмотрел эту дискуссию.
Меня не сильно интересуют способы оценки финансового результата. у меня есть хороший метод для таких оценок (многослойный мультивалютный бухгалтерский баланс).
Меня больше интересует:
1. Склоняются ли заказчики вести себестоимость склада в одной определенной валюте или связываются с партионным учетом? ИМХО, единая валюта склада предпочтительна.
2. Насколько неоптимально смотрится решение, к которому я склоняюсь, при котором в каждом складском документе имеются 3 цифры:
а. сумма позиции в валюте счета контрагента
б. сумма позиции в единой валюте склада
в. в рублях для печати счетов-фактур для белого и/или бутафорского учета.
плюс курс единой валюты склада.
плюс кросс-курс "валюта счета контрагента/валюта склада".

Если учесть еще проблемы с округлением при расчетах "от цен без НДС" или "от цен с НДС" (а разные поставщики могли по-разному считать)...
Суммарное кол-во полей может быть не таким уж маленьким...
Хотя по мне лучше много полей, чем тормоз при SQL-запросах всяких аналитических отчетов.

← →
Владислав (2003-09-30 12:12) [7]

В Российской Федерации расчеты производятся в валюте Российской Федерации - рублях...
Ибо не фиг...

← →
kaif (2003-09-30 12:24) [8]

2 Владислав © (30.09.03 12:12) [7]
Расчеты (платежи) можно производить и в рублях.
А расчеты (калькуляцию) можно и в уме случайно сделать в долларах. Надеюсь это не наказуемо? Или как?

← →
Igorek (2003-09-30 12:44) [9]

Мой заказчик был заинтересован больше в колличественном учете. Но можно ввести систему перерасчета в одну валюту. Курс - на момент поступления или поточный. База курсов на каждый день. В чем проблема? Обсуди с заказчиком, выработайте схему, зааплай.

← →
Кулюкин Олег (2003-09-30 13:01) [10]

2 kaif
> Склоняются ли заказчики вести себестоимость склада в одной определенной валюте
Хотят сумму повалютно, с возможностью конвертации в выбранную валюту.
Реально этой выбранной валютой оказывается доллар :))

← →
stone (2003-09-30 13:05) [11]

> Реально этой выбранной валютой оказывается доллар :))

Либо ЕВРО

← →
kaif (2003-09-30 13:29) [12]

Дело в том, что это не заказ. Я пишу для документации пример создания склада в своей конфигурируемой системе Allegro (альтернатива 1С). Поэтому я и ищу наиболее общее приемлемое для практического употребления решение. Но и не сложное, в то же время. Необязательно оптимальное с точки зрения места.

Пока я согласен с LordOfSilence © (30.09.03 08:33) [1]
и собираюсь сделать, пусть избыточную, но простую систему хранимых полей:

TABLE STOCK_IN (шапка документа)
=======================
ID INTEGER /*суррогатный ключ документа*/
ADATE DATE /*дата*/
ACC_ID INTEGER /*счет расчетов с поставщиками*/
CONTRAGENT INTEGER /*ссылка на справочник поставщиков*/
LAYER_ID INTEGER /*валюта документа*/
IS_EXECUTED TBOOLEAN /*птичка "оприходовано на склад"*/
TOTAL_L DECIMAL(18,2) /*всего, в валюте документа*/
TOTAL_S DECIMAL(18,2) /*всего, в валюте склада*/
TOTAL_R DECIMAL(18,2) /*всего, в рублях*/
RATE_L DECIMAL(8,2) /*курс валюты документа (к рублю)*/
RATE_S DECIMAL(8,2) /*курс валюты склада (к рублю)*/
NDS_PERCENT DECIMAL(4,2) /*ставка НДС документа*/
DOC_NUM VARCHAR(20) /*номер счета-фактуры*/
CALC_MODE INTEGER /*способ расчетов при вводе данных в сетке:
0-от цены без НДС,
1-от цены с НДС,
2 - от суммы с НДС*/

TABLE STOCK_IN_ITEM (позиции документа)
=======================================
ID INTEGER /*суррогатный ключ документа*/
N INTEGER /*суррогатный ключ позиции*/
GOODS INTEGER /*ссылка на справочник товаров*/
QUANTITY INTEGER /*количество товара*/
PRICE_L DECIMAL(8,2) /*цена в валюте документа*/
PRICE_S DECIMAL(8,2) /*цена в валюте склада*/
PRICE_R DECIMAL(8,2) /*цена в рублях с НДС*/
PRICE_R_WONDS DECIMAL(8,2) /*цена в рублях без НДС*/
AMOUNT_L DECIMAL(12,2) /*сумма позиции в валюте документа*/
AMOUNT_S DECIMAL(12,2) /*сумма позиции в валюте склада*/
AMOUNT_R DECIMAL(12,2) /*сумма позиции в рублях, с НДС*/

← →
kaif (2003-09-30 13:35) [13]

Под валютой документа подразумевается валюта сделки. Это не исключает печати "официального документа" в рублях. Однако проводится документ в валюте сделки.
Таким образом, на счет поставщика будет записана сумма в той валюте, в которой составлен документ, то есть сумма TOTAL_L. На склад начислится товар на сумму TOTAL_S. Предполагается, что весь товар будет на складе всегда измеряться в одной и той же валюте, например в USD (или EURO, или в RUB, если кому-то так нравится).

← →
panov (2003-09-30 13:44) [14]

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

← →
Delirium^.Tremens (2003-09-30 13:48) [15]

Складской учет ведется в ЕдИзмах
Бухгалтерский - в валютах

Мне больше нравится решение

> Igorek © (30.09.03 12:44) [9]

Возьми у 1С лучшее! :-)

← →
Johnmen (2003-09-30 14:12) [16]

Из личного опыта. Заказчик был удовлетворен следующим:
1. Ведется таблица курсов (в моем случае достаточно было двух валют)
2. Имеем соотв. 2 суммовых поля для 2 валют.
3. Заполнение одного из них приводит к немедленному перерасчету второго с учетом курса на указанную дату. При отсутствии курса перерасчет не производится, значение второго поля сбрасывается.
4. Если у поставщика свой собственный курс, то его значение храниться в третьем поле, и наличие его значения приоритетно над таблицей курсов.
5. Для нужд отчетов и статистики наличие рублевых значений было обязательным.

← →
Skyle (2003-09-30 14:38) [17]

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

Это было вступление о всем известных вещах ;)
Теперь по сути вопроса.

Не зная никакой конкретики ни о системе, ни о процессе, отвечаю так:

Хранение списка валют в отдельной таблице (т.н. справочник).
По любой операции указывается сумма в
1) Валюте операции
2) Строго в рублях
3) В какой-то внутренней валюте
(в зависимости от операции).

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

← →
Владислав (2003-09-30 15:00) [18]

← →
kaif (2003-09-30 15:29) [19]

В общем, я в тексте описания системы в главе "Создаем пример складской конфигурации" написал так:

Для упрощения системы все виды поступлений на склад мы объединим в один тип документа. Для того, чтобы отличать ввод между собой простые приобретения, ввод начальных остатков, поступления от поставщиков и возвраты от покупателей, в докумет мы добавим признак вида документа и ссылку на используемый счет баланса.
Из бесед с заказчиком выяснилось, что счета обязательств перед разными поставщиками ведутся в разных валютах, в зависимости от договоренности с ними. Поэтому мы будем использовать поле «валюта документа», подразумевая под валютой валюту самой сделки. Именно в этой валюте будет производиться начисление обязательств, возникающих перед поставщиком в связи с поступлением товара на склад компании TechnoTrade.
Обязательным условием заказчика было также хранение в документе рублевой информации о поставке для официальной отчетности. В частности, какждая позиция должна иметь, помимо цены сделки, также и рублевую цену, сумму без НДС, сумму НДС и сумму с НДС, связанную с валютой поставки по курсу, который в каждом документе может быть свой. Следовательно, нам нужно еще и поле «курс валюты документа», как минимум.
В части ведения учета стоимости товаров на складе наш заказчик склоняется к тому, чтобы стоимость всех товаровных запасов измерять в долларах США. так как это удобно для оперативного учета. Это означает, что нам потребуется в каждом документе хранить еще и «курс доллара США».
Еще наш заказчик утверждает, что иногда счет-фактура от поставщика присылается на фирму по электронной почте до того, как поступит товар и должна вводиться в систему заранее. То есть нужно иметь признак того, поступил товар на склад физически или еще не поступил. И только когда товар реально поступит, устанавливать «некую птичку», чтобы документ провелся в балансе.
Поразмышляв надо всем этим, мы пришли к выводу, что хорошо бы еще на всякий случай еще сделать возможность при вводе документов рассчитывать сумму разными способами, отталкиваясь либо от цены товара в рублях без НДС, либо от цены с НДС. Дело в том, что при вводе данных персонал компании TechnoTrade наверняка будет использовать сумму всего документа для контроля правильности ввода цифр. И если одни поставщики вели расчеты от цены без НДС, а другие от цены с НДС, то, в связи с ошибками округления, сумма введенного в базу данных документа может не совпасть с суммой исходного, что может вызвать осложнения на стадии внедрения системы. Разумеется, признак того, как рассчитывалась сумма, придется тоже хранить в каждом документе. К тому же придется хранить и ставку НДС. Будем исходить из того, что она одинаковая для всех товаров внутри одного конкретного документа.
Последнее обстоятельство, которое мы должны учесть, это ограничение, накладываемое системой автоматических бухгалтерских операций в Allegro. Это ограничение состоит в том, что в документе проводимые суммы должны храниться в полях таблицы документа в явном виде. Следовательно нам, понадобится для каждой позиции товара завести, как минимум два поля суммы: в валюте документа (для начисления обязательств перед поставщиком) и в долларах США склада (для начисления стоимости товарных запасов).

← →
Владислав (2003-09-30 15:38) [20]

Вау! Как много! Просто добавь еще одну (две, три) таблицу. И счастье будет.

← →
kaif (2003-09-30 15:39) [21]

Кстати, решение о связи между курсом и сделкой через дату, в большинстве случаев совершенно неприемлемо. Допустим пришли 2 рублевых счета-фактуры в 1 день. В каждом документе применялся свой курс. Это довольно типичная ситуация у большинства фирм, ведущих свои отношения с поставщиками в долларах.
Поэтому в "стандартном примере" я склоняюсь к тому, чтобы хранить курсы в документе, а не в отдельной таблице (отдельная таблица курсов "для вообще расчетов" тоже имеется, к ак у Johnmen © (30.09.03 14:12) [16]).
Что касается всего остального, то большое число полей в таблице-примере не помешает, так как это всего лишь пример и он не рассчитан на работу с миллионами записей. А вот познакомить читателя с ирудностями, которые реально возникают при складском учете (в частности с проблемой многовалютности) я считаю правильным. Так как авторы "примеров склада" обычно приводят примеры, достаточно далекие от жизни и создающие иллюзии у начинающих разработчиков.

← →
kaif (2003-09-30 15:42) [22]

Чтобы не было недоразумений...
Заказчик TechnoTrade в моем примере - гипотетический.

← →
Владислав (2003-09-30 15:54) [23]

← →
Calm (2003-09-30 16:17) [24]

> я в тексте описания системы в главе "Создаем пример складской
> конфигурации"

В тексте главы " Создаем пример складской
> конфигурации"
видимо лучше разместить эту ветку :))

← →
kaif (2003-09-30 17:57) [25]

Склад и валюты Найти похожие ветки