Добрый вечер господа!
автор"живая" тема, несмотря на выходные дни :)… у мну на все дела одна таблица - проводок, в ней суммы приходов, отгрузок, списаний, оплат и перекрытий и всех прочих хоз.операций
Привет тёзка. Вы демонстрируете один из подходов – и он имеет «право на жизнь», но замечу, что обычно делят операции по типам для достижения «логичности» системы и структуры хранения информации. Ваша идея подходит, если пытаться создавать некую «платформу» информационной системы, но здесь явно не хватает таблицы типа (так называемых «метаданных»):
1. код_операции
2. поле_1/структура информации
…
х. поле_х/структура информации
авторFinSoft. У нас одна из главных "фишек" - работа без проведения документов.
Проведение – это просто термин , означающий попадание операции в «отчёты». В КИС Lack – это «распределение» для накладной, «ввод даты оплаты» для финансового документа.
Что бы «опера» не испортили «отчётность бухгалтерии» в КИС имеются ограничение доступа к действиям пользователям (что решает проблемы озвученные Last1Cmen):
1. Запрет документа к изменению или удалению;
2. Запрет ввода операций «задним числом».
авторTrdm. Я бы не стал консультироваться у Андрея по этим вопросам. Он закоренелый технарь и находится слегка в плену DOSовской парадигмы программирования.
С момента последней нашей «тёрки» система КИС Lack переделана (на уровне исходных текстов) под мультиплатформенную парадигму и должна легко «собираться» под dos, windows, linux, macOS, PocketPC. На сайте имеются исходные текста и сборка системы УС Land под Win32 и если:
1. Вам «не влом»;
2. Хотя бы на «поверхностном» уровне знаете какой нибудь Free компилятор ANSI C;
3. Научились настраивать FireFox.
То без проблем пересобирёте систему под любой ПК платформой. ОС в задаче ТС абсолютно не важна, м.б. какое-то значение имеет механизм доступа к данным:
1. Навигационный
2. Реляционный. Хотя и это не влияет на структуры хранения информации (таблицу БД).
авторPrimaryPro
1. Я так понял, что создается журнал финансовых документов (отдельно от журнала складских документов), где каждому финансовому документу привязывается один или несколько документов из журнала складских документов (или не привязывается, если фин. документ не связан с дурнадом складских документов)?
2. Как вести отдельно наличные фин.документы (касса) и безналичные фин.документы (банк) с позиции разработчика?
Вы всё правильно поняли – достаточно «факультативной» ссылки на уникальные код документа «журнала складских документов». Все механизмы «привязок» подробно описаны на страничке e-book: технологии и отчёты по финансовым документам. Для примера приведу структуру таблицы «кассовых документов» из описания laks_dbf.doc комплекса документации системе (можно взять на сайте):
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
Cash_ord.dbf Кассовые ордера.
codCash c 4 Код кассового документа
tip c 1 тип документа. "1" - ПКО, "2" - РКО
dat d 8 его дата
number c 12 номер
sum n 15 . 2 сумма документа
client c 4 сист.код клиента
reason c 150 основание платежа
datPay d 8 дата оплаты
idCodInv c 5 код накладной или пусто
dmove l 1 рабочее поле АРМ директора
keeping l 1 признак отнесения оплаты к товарным операциям
closes l 1 признак абсолютного запрета изменений
dGr l 1 метка групповой операции
dProv l 1 признак проводимости документа
stat l 1 признак запрета операции
tabel3 c 4 код оператора добавивщего/изменившего документ
codStores c 2 код связанного с операций склада
tabel c 4 рабочее поле для совместимости
lab1 c 25 системная метка.
CashMain.ntx into client+Dtos(dat) CO_CLIENT_DAT 1
CashCode.ntx into codCash CO_CODCASH 2
CashDate.ntx into Dtos(dat)+Upper(number) CO_DAT_NUMBER 3
Cash_inv.ntx into idCodInv CO_IDCODINV 4
автор3. В товарной накладной имеется реквизит "отсрочка платежа". Для чего?
В принципе спецы уже ответили, но в основном:
1. Анализ дебиторкой или кредиторской задолжности;
2. Выявление «просроченных» оплат;
3. Инфа для контрагента и торгового представителя о сроках оплат.
