Ппоблема трех раскладок решается двумя языками ввода, и для одного из них две раскладки клавиатуры. Язык ввода переключается ctrl-shift, а раскладка в пределах языка alt-shift. En, Ru, Ua. Английский (En)и украинский языки (две раскладки Ukr Ua и Ukr Ru).
Я настроил себе переключение тоже через AutoHotKey. Но я поборол проблемы с консолью.
Язык ввода меняю через длинное нажатие на LShift / RShift, предыдущую раскладку сохраняю.
При такой структуре есть необходимость ускорять расчеты на начало периода. Т.к. весь учет происходит от начала истории. Есть разные способы. Я для себя изобрел следующий:
В таблицу OPER добавляется поле "ПРИЗНАК ОСТАТКА" у меня OST, для обычной проводки в этом поле 0. Периодически (раз в день/неделю/месяц/квартал/год) происходит закрытие периода и в таблицу OPER добавляются текущие остатки по счетам/организациям. Но не виде проводки, а одиночные строки с полем OST = 1. И в отдельную таблицу вносится дата закрытия (у меня PERIOD) В дальнейшем для получения отчетов с остатками на начало по таблице PERIOD находим ближайшую дату снизу к дате начала периода. И отчет модернизируется до where (o.ost = 1 and o.date_oper = 'дата закрытия') or (o.ost = 0 and o.date_oper between 'дата закрытия' + 1 and 'конечная дата отчета')
Такая схема работает у меня очень давно и проблем с производительностью нет никаких
Еще раз про структуру таблицы "полупроводок" пусть будет OPER
Дата
ID счета
ID контрагента (склад/сотруник/покупатель/поставщик и т.д.)
Знак (1 для дебета, -1 для кредита)
Сумма
ID книги (в какой должна фигурировать проводка)
Пара (поле связывающее строку дебет со строкой кредит, в моем случае это поле одинаковое для двух строк)
Далее необязательные поля, но важные
ID документа (у одного документа есть набор проводок)
Примечание (описание проводки)
У меня еще есть дополнительные поля, но для объяснения они пока не важны
Получение одной проводки из такой таблицы получается при помощи join select d.*, k.* from oper d join oper k on k.para = d.para and k.sign = -1 where d.sign = 1
В таблицу проводок добавляется поле LedgerID и главная книга это простой отчет с остатком на начало, оборотами и остатком на конец
select LedgerID, AccountId, sum(case when sign = 1 and date_oper < '01.01.2021' then summa else 0 end) debet_begin, sum(case when sign = -1 and date_oper < '01.01.2021 then summa else 0 end) kredit_begin, sum(case date_oper < '01.01.2021 then sign * summa else 0 end) summa_begin, sum(case when sign = 1 and date_oper >= '01.01.2021' then summa else 0 end) debet_turnout, sum(case when sign = -1 and date_oper >= '01.01.2021' then summa else 0 end) kredit_turnout, sum(case date_oper >= '01.01.2021' then sign * summa else 0 end) sum_turnout, sum(case when sign = 1 then summa else 0 end) debet_end, sum(case when sign = -1 then summa else 0 end) kredit_end, sum(sign * summa) summa_end from oper where date_oper <= '31.01.2021' group by LedgerID, AccountId
select o.CustId, o.AccountId, min(c.adress), sum(o.summa * o.sign) from oper o
left join customers c on c.id = o.CustId
group by o.CustId, o.AccountId
Итоги считаются по паре CustID, AccountId. А дальнейшие подитоги это не дело СУБД, легко решается на уровне генератора отчетов. Но можно и извратиться для получения этих данных одним запросом. но тут надо включать тяжелую артиллерию SQL - "WITH RECURSIVE"
Вам непонятно как сделать сумму по "дереву" счетов? В древовидном справочнике счетов есть поле "Родитель". Можно добавить еще одно "Родитель для группировки". Здесь и будет самьій верхний уровень. Зачем добавлять это поле в проводку я не понимаю.
select СЧЕТ.ГЛАВНЫЙ_СЧЕТ, sum(case when ПРОВОДКИ.ЗНАК = 1, ПРОВОДКИ.СУММА else 0 end) debit_turnout, sum(case when ПРОВОДКИ.ЗНАК = -1, ПРОВОДКИ.СУММА else 0 end) credit_turnout, from ПРОВОДКИ join СЧЕТ on СЧЕТ.id = ПРОВОДКИ.счета group by СЧЕТ.ГЛАВНЫЙ_СЧЕТ
У меня на этот случай нет никаких ограничений на уровне СУБД. Пользователь сам решает какой счет использовать и с каким уровнем вложенности работать. Для запрета на уровне СУБД в справочнике счетов достаточно ввести поле (самый низкий уровень), и разрешать использовать только такие поля. Поле обновлять автоматически при редактировании справочника счетов.
У меня такие касио. Идут с 2009 на одной батарейке
Яка прикра новина!
А не воевать совсем не вариант?
Как будем LEFT JOIN форматировать?
Подозреваю, что никак
Возможно я не совсем понимаю понятие "консоль". У меня в FAR и cmd переключает
Пример ниже
Вот пример моего скрипта:
Ппоблема трех раскладок решается двумя языками ввода, и для одного из них две раскладки клавиатуры. Язык ввода переключается ctrl-shift, а раскладка в пределах языка alt-shift. En, Ru, Ua. Английский (En)и украинский языки (две раскладки Ukr Ua и Ukr Ru).
Я настроил себе переключение тоже через AutoHotKey. Но я поборол проблемы с консолью.
Язык ввода меняю через длинное нажатие на LShift / RShift, предыдущую раскладку сохраняю.
Первая задача сводится наличию не менее трех пар карт "квадратов"
Паляниця
А зачем боятся джойна? Хранение в справочнике операций счет, главный в группировке решает все проблемы
При такой структуре есть необходимость ускорять расчеты на начало периода. Т.к. весь учет происходит от начала истории. Есть разные способы. Я для себя изобрел следующий:
В таблицу OPER добавляется поле "ПРИЗНАК ОСТАТКА" у меня OST, для обычной проводки в этом поле 0.
Периодически (раз в день/неделю/месяц/квартал/год) происходит закрытие периода и в таблицу OPER добавляются текущие остатки по счетам/организациям. Но не виде проводки, а одиночные строки с полем OST = 1. И в отдельную таблицу вносится дата закрытия (у меня PERIOD)
В дальнейшем для получения отчетов с остатками на начало по таблице PERIOD находим ближайшую дату снизу к дате начала периода.
И отчет модернизируется до
where (o.ost = 1 and o.date_oper = 'дата закрытия') or (o.ost = 0 and o.date_oper between 'дата закрытия' + 1 and 'конечная дата отчета')
Такая схема работает у меня очень давно и проблем с производительностью нет никаких
Еще раз про структуру таблицы "полупроводок" пусть будет OPER
Дата
ID счета
ID контрагента (склад/сотруник/покупатель/поставщик и т.д.)
Знак (1 для дебета, -1 для кредита)
Сумма
ID книги (в какой должна фигурировать проводка)
Пара (поле связывающее строку дебет со строкой кредит, в моем случае это поле одинаковое для двух строк)
Далее необязательные поля, но важные
ID документа (у одного документа есть набор проводок)
Примечание (описание проводки)
У меня еще есть дополнительные поля, но для объяснения они пока не важны
Получение одной проводки из такой таблицы получается при помощи join
select d.*, k.* from oper d
join oper k on k.para = d.para and k.sign = -1
where d.sign = 1
В таблицу проводок добавляется поле LedgerID и главная книга это простой отчет
с остатком на начало, оборотами и остатком на конец
select LedgerID, AccountId,
sum(case when sign = 1 and date_oper < '01.01.2021' then summa else 0 end) debet_begin,
sum(case when sign = -1 and date_oper < '01.01.2021 then summa else 0 end) kredit_begin,
sum(case date_oper < '01.01.2021 then sign * summa else 0 end) summa_begin,
sum(case when sign = 1 and date_oper >= '01.01.2021' then summa else 0 end) debet_turnout,
sum(case when sign = -1 and date_oper >= '01.01.2021' then summa else 0 end) kredit_turnout,
sum(case date_oper >= '01.01.2021' then sign * summa else 0 end) sum_turnout,
sum(case when sign = 1 then summa else 0 end) debet_end,
sum(case when sign = -1 then summa else 0 end) kredit_end, sum(sign * summa) summa_end
from oper
where date_oper <= '31.01.2021'
group by LedgerID, AccountId
Все же "книга" это свойство "проводки". Наравне со счетом, организацией, суммой.
Для ускорения можно сначала сгруппировать, а потом уже на готовые данные делать join.
Обычно такой запрос тоже делается не по всем счетам, а только по какой-то группе. Для этого я объединяю с таблицей групп счетов.
Структура такой таблицы простая (id_группы, id_счета)
Да, конечно есть.
select o.CustId, o.AccountId, min(c.adress), sum(o.summa * o.sign) from oper o
left join customers c on c.id = o.CustId
group by o.CustId, o.AccountId
Итоги считаются по паре CustID, AccountId. А дальнейшие подитоги это не дело СУБД, легко решается на уровне генератора отчетов.
Но можно и извратиться для получения этих данных одним запросом.
но тут надо включать тяжелую артиллерию SQL - "WITH RECURSIVE"
Я не совсем понимаю вопрос.
Вам непонятно как сделать сумму по "дереву" счетов?
В древовидном справочнике счетов есть поле "Родитель".
Можно добавить еще одно "Родитель для группировки". Здесь и будет самьій верхний уровень. Зачем добавлять это поле в проводку я не понимаю.
select СЧЕТ.ГЛАВНЫЙ_СЧЕТ,
sum(case when ПРОВОДКИ.ЗНАК = 1, ПРОВОДКИ.СУММА else 0 end) debit_turnout,
sum(case when ПРОВОДКИ.ЗНАК = -1, ПРОВОДКИ.СУММА else 0 end) credit_turnout,
from ПРОВОДКИ
join СЧЕТ on СЧЕТ.id = ПРОВОДКИ.счета
group by СЧЕТ.ГЛАВНЫЙ_СЧЕТ
У меня на этот случай нет никаких ограничений на уровне СУБД. Пользователь сам решает какой счет использовать и с каким уровнем вложенности работать.
Для запрета на уровне СУБД в справочнике счетов достаточно ввести поле (самый низкий уровень), и разрешать использовать только такие поля. Поле обновлять автоматически при редактировании справочника счетов.