|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Схемы построения учетной системы. Нужна критика. В качестве основного элемента является документ. На основании документа выполняются соответствующие проводки. По поводу хранения движения документа у меня появились два варианта реализации. Первая схема. За основу взят механизм 1с. При создании нового документа и его проведении в базе создается новая запись. При изменении соответствующая запись модифицируется. При удалении ставится метка. Для отслеживания изменения записей ведется история изменений. Для справочниках необходимо вести периодические реквизиты. Вторая схема. За основу взят механизм Axapta . Проводки помечаются как удаленные, при каждом изменении документа создается новая запись. Старая помечается как удаленная. Минусы разбухание базы. Плюсы не надо вести историю изменений. Может кто знает еще какие варианты? Также интересует мнение тех кто реализовывал такие схемы, какие ждут подводные камни? Заранее спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.11.2007, 14:38 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
А что мешает объединить эти варианты ? Хочет заказчиг историю изменнений - включил соответствующую опцию и вперёд ... |
|||
:
Нравится:
Не нравится:
|
|||
26.11.2007, 15:56 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Бизон Может кто знает еще какие варианты? Знает. История изменений не ведется. Модифицируй чего хочешь. Удаляется документ без всяких следов. Плюсы - лишнее место не занимается, транзакции не используются, летает очень быстро. Галактика. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.11.2007, 16:03 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
БизонМожет кто знает еще какие варианты? Также интересует мнение тех кто реализовывал такие схемы, какие ждут подводные камни? Заранее спасибо. Я использовал, нечто похожее на первую схему (собственно он появился намного раньше 1С ). Документ идет по статусам и изменения записываются (или не записываются) в историю в зависимости от статуса. Никого не интересует созданный документ и что с ним делают пока он "не оформлен" (удаляют, мишут матерные слова и тд). А вот тот кто оформил берет на себя ответственность и должен попасть в историю В зависимости от ваших статусов вы записываете нужную Вам историю. Второй механизм связан с не лучшей реализацией и "крив" изначально. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.11.2007, 17:11 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
> За основу взят механизм 1с Взять один кусок дерьма и сделать другой такой же - это такая фишка? > За основу взят механизм Axapta Вы ее структуру данных видели? Это бред пьяных китайских школьников. Вы выбираете не те примеры для подражания. > Плюсы не надо вести историю изменений Каша у Вас в голове, дружище. Может, начнете с теоретической подготовки? Зачем писать говенный код, если заранее понятно, что он говенный? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.11.2007, 17:42 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
guest_20040621> За основу взят механизм 1с Взять один кусок дерьма и сделать другой такой же - это такая фишка? > За основу взят механизм Axapta Вы ее структуру данных видели? Это бред пьяных китайских школьников. Вы выбираете не те примеры для подражания. > Плюсы не надо вести историю изменений Каша у Вас в голове, дружище. Может, начнете с теоретической подготовки? Зачем писать говенный код, если заранее понятно, что он говенный? ну поливать все это много ума не надо - в мире куча дураков которые сидят на 1С и той же Аксапте, я бы хотел услышать ваш гениальных подход!!! ... |
|||
:
Нравится:
Не нравится:
|
|||
26.11.2007, 17:47 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
guest_20040621> За основу взят механизм 1с Взять один кусок дерьма и сделать другой такой же - это такая фишка? Здорово! Вы наверно знаете механизм контроля лучше, не желаете поделиться??? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.11.2007, 17:49 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
andbaryВы наверно знаете механизм контроля лучше, не желаете поделиться??? Позвольте осведомиться, о контроле чего топик по-Вашему? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.11.2007, 17:55 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
> в мире куча дураков которые сидят на 1С и той же Аксапте Не только. Отдельные кучки дебилов - на Галактике и прочем. > я бы хотел услышать ваш гениальных подход!!! Боюсь, Вы не сможете себе это позволить. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.11.2007, 17:56 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
> Вы наверно знаете механизм контроля лучше Чего контроля и чего лучше? Лучше одинце? Хуже одинце ничего быть не может. Любая реализация заведомо лучше. > не желаете поделиться??? Чем, дружище? Механизмами контроля? Легко. Задавайте вопросы. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.11.2007, 17:59 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Сергей ВаскецовПозвольте осведомиться, о контроле чего топик по-Вашему? А для чего по вашему должна сохраняться история??? (если не для контроля) guest_20040621Чего контроля и чего лучше? Лучше одинце? Хуже одинце ничего быть не может. Любая реализация заведомо лучше. > не желаете поделиться??? Чем, дружище? Механизмами контроля? Легко. Задавайте вопросы. Ну так опишите свой механизм контроля? (сохранения истории изменений в данном контексте) Если вы обижены чем то на 1це, это не повод кричать, что все у них плохо. Многие механизмы которые они используют вполне функциональны и используются еще в очень многих системах. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.11.2007, 18:13 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
PostgreSQL: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
СправочникБоевой.id) ... И заметьте - есть история - чего, кто и когда менял. Таблица СправочникСИсторией хранится в одной схеме (ее можно вынести на другой дисковый массив, к примеру) и содержит ВСЕ версии ВСЕХ записей Справочника, СправочникБоевой - в другой схеме - на СамомБыстромМассиве, к примеру. Можно оформить процедуру автоматического создания боевых таблиц вместе с триггерами - то есть на каждую таблицу надо будет писать 1 запрос и вызов функции. Чего тут обсуждать ? 10 строчек кода или чужое одноэсное говно ? :( ... |
|||
:
Нравится:
Не нравится:
|
|||
26.11.2007, 19:03 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
> Ну так опишите свой механизм контроля? (сохранения истории изменений в данном контексте) Задайте конкретный вопрос - получите конкретный ответ. > Если вы обижены чем то на 1це Дружище, мне глубоко плевать на одинце и аналогичные поделки. Что значит "обижен"? Это тупо и криво сделанный софт, который незачем обсуждать. Хотите что-то обсудить - специально для желающих есть соответствующий форум, там и развлекайтесь. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.11.2007, 19:56 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
strizh Вы предлагаете по сути разделит на две базы. Основная рабочая и архивная? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.11.2007, 20:38 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Уважаемый Бизон!Мне кажется некорректной сама постановка вопроса.Для начала определитесь ,что у вас документ а что проводка.Не зная, что именно вы учитываете,трудно давать вменяемые советы.История изменений в отдельной базе? На то должны быть очень веские основания.Тем более на триггерах.Не понятно для чего вам нужна история изменений.Если чтоб было-то флаг вам в руки.Идея дублировать данные в другой базе мне как-то не очень нравится.Просто потому, что обьем кода и данных растет в геометрической прогрессии,и это не есть хорошо.В банковских системах обычно весь учет в двух таблицах.1 таблица собственно описание операции :кто когда кому за что и сколько ,разумеется только Id ентификаторы.Во второй таблице счета.Надеюсь вам не нужно обьяснять что есть счет.Остальное все возможные справочники на которые ссылаются идентификаторы из первой таблицы.Да кстати структура счета (20 разрядов) позволяет разносить любую аналитику.То-что вы называете субконто нафиг не упало потому как есть план счетов, где все четко и подробно расписано на какие счета чего должно падать.Кроме того есть куча инструкций как именно нужно фиксировать ваши операции в системе.Одна операция может давать несколько записей в основной таблице,(механизм сложных проводок) ну и т.д. и т.п.Не скажу ,что это есть само совершенство, но точно делалось не дураками и не с бухты барахты.Да кстати, по -поводу журнала изменений ну заведите еще одну таблицу и пишите туда ,что вам хочется писать.Главное чтобы вы потом смогли разобраться кто что и с кем :) ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 01:17 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Как лучше - это вопрос не совсем корректный, потому что задачи ваши неизвестны. Я думаю, что механизм отделения проводок от документов нужен не всегда. Например, он нужен, если у вас есть много документов разных типов, которые имеют очень разную структуру и разные методы расчета влияния документа на состояние предприятия. Тогда удобно использовать проводки для того, чтобы свести разнообразие к однообразию один раз, и не сводить каждый раз при расчетах. Если же движение ресурсов предприятия, учет которых вы автоматизируете, достаточно прямолинеен, то необходимости в проводках на мой взгляд нету. Как и в истории изменений. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 01:38 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
andbary Сергей ВаскецовПозвольте осведомиться, о контроле чего топик по-Вашему? А для чего по вашему должна сохраняться история??? (если не для контроля) 1. Например, чтобы можно было "вытащить" значение наименования контрагента, которое было месяц назад, в отчет, а не для контроля. Есть еще способы использования протокола изменений. Я, например, по сохраненным изменениям формирую отчет о выполненной работе за период, а не вручную, как многие. 2. В корне топика не вижу, что основной темой является протоколирование изменений и хранение этой истории, разве только как небольшая часть того, что интересует автора. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 09:47 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
БизонСхемы построения учетной системы. Нужна критика Критиковать приведенные "системы" по уже описанным guest_ом причинам не буду, полностью согласен с его мнением, уже приведенным здесь. Как у нас в случае, если по документу возможно появление проводок (только неочевидные для автора топика "особенности", которые он хотел подсмотреть в других системах). 1. Ничего с проводками "при каждом изменении документа" не происходит. Изменение документа возможно только в том случае, если он не утвержден (множество статусов здесь не обсуждаем). Раз документ не утвержден - с ним можно делать все, что хочется. Такая задача (чтобы проводки всегда соответствовали документу независимо от его статуса) может придти в голову только инвалидам детства, это бредовая задача, разве только блокировок наплодить и сервер подвесить удастся при массовых изменениях документов. Безусловно, если пользователь НУ ОЧЕНЬ СИЛЬНО хочет сгенерить проводки по черновому документу, он это может сделать. После утверждения документа в нем менять ничего нельзя, соответственно, (пере)генерить проводки можно в любой момент, пока они не утверждены. 2. Протоколирование изменений реализовано так, что оно ничего не знает про отдельные документы и проводки. Ему почти без разницы что протоколировать (разве что сразу же не делал возможность протоколирования всяких блобов, а то даже местным админам иногда опасно давать такое в руки, то есть, для них это by design). Включается, отключается, настраивается отдельно по каждому полю, если есть необходимость, можно временно включить или отключить все враз. Вся настройка отдана местным админам на откуп. Но это уже мелочи. 3. При удалении запись физически удаляется независимо от того, что это за запись. Утверждены регламены, что можно удалять (и как именно, если надо), что нельзя. Настроены права доступа так, что просто так никто не то, что удалить, а даже близко подойти не сможет. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 10:02 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Для начала объектом для автоматизации является склад. После откатки технологии, планируется сделать торговлю и производство. В качестве основного элемента системы предполагается использовать документ. Документ должен выполнят движения по следующим разрезам учета: бухгалтерскому, налоговому и оперативному. К сожалению документ планируется препроводить при внесении изменений. Поэтому соответствующие проводки необходимо откатывать и делать новые. Возможно существует более эффективный алгоритм внесения изменений и выполнения изменений в базе данных без использования проводок.? Буду признателен за любые советы в данном направлении. История изменений нужна для формирования как бы следа документа, когда, что и кто изменил. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 11:00 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Бизон Документ должен выполнят движения по следующим разрезам учета: бухгалтерскому, налоговому и оперативному. . Куяясе! У вас круто задумано!!! ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 11:17 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
БизонДокумент должен выполнят движения по следующим разрезам учета: бухгалтерскому, налоговому и оперативному Для складских документов ОУ вполне можно вести по самому документу и картотеке, проводки здесь дюже лишние. БизонК сожалению документ планируется препроводить при внесении изменений За этой фразой может скрываться все, что душе угодно. На всякий случай внимательно прочитайте п.1 моего сообщения выше. БизонВозможно существует более эффективный алгоритм внесения изменений и выполнения изменений в базе данных без использования проводок.? Какая-то каша у Вас. Проводки нужны для отражения документа в определенном учете (прежде всего это касается регламентированных учетов). Проводки никакого отношения к "внесения изменений и выполнения изменений в базе данных" не имеют. БизонИстория изменений нужна для формирования как бы следа документа, когда, что и кто изменил. Забудьте пока про историю изменений. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 11:32 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
2 автор В принципе, можно фсе, например превратить документ с его проводками в маленький детектив. Однако вряд ли ваше руководство намерено вырастить из кладовщиков авторов детективов, а затем заняться их (детективов) разгадыванием. Сергей Васкецов , +1 ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 12:01 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Возможно я неправильно использую понятие проводки. Для меня это механизм разнесения данных первичного документа после нажатия кнопки «выполнить» оператором по разрезам учета. По поводу п.1. Документ может имеет проходить следующие состояниия. Набран –сохранен – проведен(выполнены проводки) - отменен(откат проводок) – изменен(история изменений) – перепроведен(выполнены проводки). ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 12:22 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
БизонДокумент может имеет проходить следующие состояниия. Набран –сохранен – проведен(выполнены проводки) - отменен(откат проводок) – изменен(история изменений) – перепроведен(выполнены проводки). Странные состояния. Для складских документов более чем достаточно статуса "Утвержден" (если нет - правится как угодно, "Черновик") и аналогичного статуса проводок. В статусах "отменен(откат проводок) – изменен(история изменений) – перепроведен(выполнены проводки)" вообще никакого смысла не вижу. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 12:32 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
БизонВозможно я неправильно использую понятие проводки. Для меня это механизм разнесения данных первичного документа после нажатия кнопки «выполнить» оператором по разрезам учета. По поводу п.1. Документ может имеет проходить следующие состояниия. Набран –сохранен – проведен(выполнены проводки) - отменен(откат проводок) – изменен(история изменений) – перепроведен(выполнены проводки). Вообще в бухгалтерии нет "отката" проводки. Делается сторнирующая проводка. поэтому состояния автор отменен(откат проводок) – изменен(история изменений) – перепроведен(выполнены проводки) не совсем понятны и только будут вносить путаницу в учет. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 12:34 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Присоединюсь к топику следующей мыслью. Есть поля документа, которые после "проведения/утверждения/постирования/изменения статуса" можно поменять, есть которые нельзя. Best practice говорит, что удалять физически документ с проводками не стоит. Мысль разносить по разным таблицам разные части учета (бух, налоговый, оперативный) - весьма плодотварна, Еще отдельно несите дебиторов, кредиторов, банк, основные средства, признаки и объекты управленческого учета. Смотрите как устроен SAP = мудрость (после 1С) ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 12:49 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
LunxСмотрите как устроен SAP = мудрость (после 1С) Весьма бездарно SAP устроен, не надо ля-ля. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 12:58 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
sergey888 Вообще в бухгалтерии нет "отката" проводки. Делается сторнирующая проводка. А в оперативном учете есть :-) и что делать? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 13:04 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Сергей Васкецов LunxСмотрите как устроен SAP = мудрость (после 1С) Весьма бездарно SAP устроен, не надо ля-ля. По теме двух веток у меня зародилась мысль что сергей все таки разработал идеальную систему... Я прямо таки жду презентации - скоро закроются мягкие и сапы - это ли не план Путина!!! ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 13:04 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
простите за оффтопик - накипело!!! ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 13:07 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
niki4550148По теме двух веток у меня зародилась мысль что сергей все таки разработал идеальную систему В части, обсуждаемой в топике, ее можно улучшить не намного. Про идеальность я не утверждал. Ошибки в известных системах есть и повторять их у себя причин не вижу. На всякий случай комментарии "саперу" и Вам тоже. LunxBest practice говорит, что удалять физически документ с проводками не стоит. Здравая логика говорит, что возможность или невозможность удаления документа никак не связана с наличием или отсутствием у него проводок, а определяется исключительно статусом документа (ну и полномочиями пользователя). LunxМысль разносить по разным таблицам разные части учета (бух, налоговый, оперативный) - весьма плодотварна Она бесконечно бредова по сути. Что Вы будете делать при добавлении еще 5-10 видов учета? LunxЕще отдельно несите дебиторов, кредиторов, банк Куда "нести"? Если разнести отдельно - тоже спорная тема, на пустом месте придумать себе задачу сопоставления дебиторов и кредиторов и доблестно ее решать. У меня одно и то же предприятие может быть и дебитором, и кредитором, и банком (реквизиты его вводятся один раз в одном месте, для непонятливых), все взаиморасчеты выполняются как 2 пальца. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 13:41 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Ivan Durak sergey888Вообще в бухгалтерии нет "отката" проводки. Делается сторнирующая проводка. А в оперативном учете есть :-) В ОУ даже сложно придумать корректное обоснование необходимости формирования проводок. А уже об их откате и говорить не приходится. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 13:42 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Ivan Durak sergey888 Вообще в бухгалтерии нет "отката" проводки. Делается сторнирующая проводка. А в оперативном учете есть :-) и что делать? Пример в студию. Вариант с ошибкой оператора не предлагать! ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 13:47 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Сергей Васкецов [quot Lunx]Мысль разносить по разным таблицам разные части учета (бух, налоговый, оперативный) - весьма плодотварна Она бесконечно бредова по сути. Что Вы будете делать при добавлении еще 5-10 видов учета? А Вы хотите сказать что по видам учета разделять не надо ? Даже если Вы и придумаете еще 10 видов учета - это наоборот удобно. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 13:57 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
PiterBest Сергей Васкецов [quot Lunx]Мысль разносить по разным таблицам разные части учета (бух, налоговый, оперативный) - весьма плодотварна Она бесконечно бредова по сути. Что Вы будете делать при добавлении еще 5-10 видов учета? А Вы хотите сказать что по видам учета разделять не надо ? Я хочу сказать, что не надо разносить по разным таблицам . PiterBestДаже если Вы и придумаете еще 10 видов учета - это наоборот удобно. То есть, добавлять новые таблицы, изменять логику работы системы и писать новые отчеты при добавлении нового учета - это "удобно"? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 14:00 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Необходимость организации ведения разных таблиц для разных видов учета продиктова требованем к скорости обработки данных. Как пример - дебиторская задолженность. В SAP погашение задолженности например пишется в главную книгу общей суммой, а в книгу дебиторов - с выравниванием по открытым позициям. Для чего это надо. При составлении баланса (главная книга) нужны данные только по обороту, сальдо счета, информация по каждой отдельной позиции - лишняя. При составлении же акта взаиморасчетов - без нее никак. Выражается это в том, что у нас есть SELECT на разные таблицы, в зависимости от контекста и условие стоит не счет=выбранный счет когда Вы все пишите в главную книгу, где счетов мильен, а дебитор=выбранный дебитор где дибиторов - ну сколько бедиторов у компании. Желание свалить все в кучу говорит о том, что человек не занимается оптимизацией скорости выборок. На Ваш вопрос - если поялвяется еще 10 видов учета - да, надо делать 10 новых таблиц и писать функционал на них. Как пример - учет дебиторской задолженности в 1С - один регистр - сводный по суммам, второй по открытым позициям, срокам платежа. В этом смысле 1С растет (причем старается в сторону SAP, вроде). ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 14:18 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
LunxНа Ваш вопрос - если поялвяется еще 10 видов учета - да, надо делать 10 новых таблиц и писать функционал на них. Как пример - учет дебиторской задолженности в 1С - один регистр - сводный по суммам, второй по открытым позициям, срокам платежа. В этом смысле 1С растет (причем старается в сторону SAP, вроде). Дальнейшее обучение индивидуумов, искалеченных SAP-ом и 1С-ом, буду проводить за деньги. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 14:23 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
To Бизон: >Вы предлагаете по сути разделит на две базы. Основная рабочая и архивная? Нет :) Посмотрите, как устроены нормальные базы данных (MS, Oracle, Postgres). Таблицы создаются не просто в базе данных, а в одной из схем базы. Зачем схемы - читайте умные книги и пр. Например, для приема, о котором я говорил выше. Насчет проведения. PostgreSQL. В таблице ТаблицаДокументов есть колонка REGISTERED - флажок проведен-нет и колонка ID. Код: plaintext 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. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51.
И что тут обсуждать ? Один триггер и 3 функции ? Посему совет Бизону - сначала изучите базовые возможности выбранной Вами СУБД, а потом двигайтесь к цели. А если будете логику на клиенте делать - получите еще одну 1С, только хуже ! ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 14:36 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Если я правильно понял предложенный Вами механизм. Вы предлагаете использовать только одно состояние документа и после его утверждения не менять. Все дальнейшие операции проводить только сторнированием? А как быть например, есть приходная накладная мы приняли товар. Записали. Провели. Через день приходить ее замена ошиблись с ценой. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 15:06 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
БизонА как быть например, есть приходная накладная мы приняли товар. Записали. Провели. Через день приходить ее замена ошиблись с ценой. 1. Что значит "провели"? Если говорить о бухучете, то никто не мешает проверять и утверждать проводки в конце учетного периода, а не в онлайне. 2. Что мешает разутвердить документ, исправить его и утвердить заново? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 15:25 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Сергей Васкецов БизонА как быть например, есть приходная накладная мы приняли товар. Записали. Провели. Через день приходить ее замена ошиблись с ценой. 1. Что значит "провели"? Если говорить о бухучете, то никто не мешает проверять и утверждать проводки в конце учетного периода, а не в онлайне. 2. Что мешает разутвердить документ, исправить его и утвердить заново? Чухня. Мешает принцип - согласно которому проведенный документ можно только сторнировать, а не исправлять задним числом. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 15:33 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
БизонЕсли я правильно понял предложенный Вами механизм. Вы предлагаете использовать только одно состояние документа и после его утверждения не менять. Все дальнейшие операции проводить только сторнированием? А как быть например, есть приходная накладная мы приняли товар. Записали. Провели. Через день приходить ее замена ошиблись с ценой. А деньги уже проплатили за товар? если проплатили, то как будете возвращать переплаченную сумму? Кто подписал договор с этим поставщиком? В таких случаях надо выгонять коммерческого директора, т.к. явно просмартивается сговор с поставщиком, а вы вместо этого пытаетесь автоматизировать процесс отмывания денег. В когда в магазине товар покупаете, то сразу его оплачиваете. Даже если продавец ошибся с ценой, то он не придет к Вам домой чтобы вернуть то, что вы переплатили. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 15:35 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
LunxМешает принцип - согласно которому проведенный документ можно только сторнировать, а не исправлять задним числом. Ну и в топку этот принцип, если он жить мешает. Если система не умеет корректно проводить изменения задним (передним :)) числом - в топку эту систему. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 15:35 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Бизон скромное предложение...возьмите за основу самую распространенную практику (см. рис) - надежно - практически безразмерно для расширения - просто в реализации Основные правила, вкратце: - данные учета - таблица(ы) фактов с необходимыми для целей учета и отчетности измерениями. - вся отчетность формируется только по данным учета, забудьте на время что есть какие-то документы и прочие источники данных - документ = источник данных, регистратор событий, фактов - Процедура учета выполняет конвертацию данных документа (или другого источника данных) в структуру данных учета (учетного регистра если нравится) - учет может быть многоуровневый, т.е. учет одного документа формирует таблицу фактов №1, если учет выполнен, на основании учтенных данных может формироваться таблица фактов №2 и т.д. - учет может быть многоплановый, т.е. один и тот же документ может быть отражен параллельно в более чем одной таблице фактов. - Учтенный документ недоступен для изменения, чтобы изменить документ необходимо отменить его учет - Процедура отмены учета отслеживает возможность внесения изменений Появляются новые документы или требуются новые структуры фактов - внесение изменений довольно простая процедура, не требующая останова. По поводу того, удалять или помечать записи учета как недействительные - как нравится. Если не нужно хранить историю - удаляйте, нужно - помечайте. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 15:50 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Сергей Васкецов LunxМешает принцип - согласно которому проведенный документ можно только сторнировать, а не исправлять задним числом. Ну и в топку этот принцип, если он жить мешает. Если система не умеет корректно проводить изменения задним (передним :)) числом - в топку эту систему. А разве сторнирование не является исправлением ошибки? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 16:01 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
sergey888 БизонЕсли я правильно понял предложенный Вами механизм. Вы предлагаете использовать только одно состояние документа и после его утверждения не менять. Все дальнейшие операции проводить только сторнированием? А как быть например, есть приходная накладная мы приняли товар. Записали. Провели. Через день приходить ее замена ошиблись с ценой. А деньги уже проплатили за товар? если проплатили, то как будете возвращать переплаченную сумму? Кто подписал договор с этим поставщиком? В таких случаях надо выгонять коммерческого директора, т.к. явно просмартивается сговор с поставщиком, а вы вместо этого пытаетесь автоматизировать процесс отмывания денег. В когда в магазине товар покупаете, то сразу его оплачиваете. Даже если продавец ошибся с ценой, то он не придет к Вам домой чтобы вернуть то, что вы переплатили. Не проплатили. А если наоборот он осталься должен. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 16:04 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
sergey888А разве сторнирование не является исправлением ошибки? :) Методов исправления ошибок много, например, сделать с нуля новую БД и заново все ввести. Сторнирование - это операция изменения чего-то, что менять напрямую нельзя, но очень хочется, она имеет свою дату, отличную от даты сторнируемой операции. Ограничивать сторнирование только лишь исправлением ошибок не стоит. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 16:14 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
БизонА если наоборот он осталься должен. Разноска платежей вообще-то отдельная операция. И уж тем более в ней нечего делать складским документам. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 16:15 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Предлагаю разобраться на примере конкретной операции. Сидит оператор на складе, ему принесли приходную накладную. Вводит. Нажимает кнопку «ОК». Указанное количество товара соответственно увеличивает остатки на складе товара. Сумма в накладной увеличивает наш долг поставщику. На следующий день поставщик нашел ошибку, не по той цене отгрузил. Присылает замену. А может только в конце месяца. На цену товара плевать всем. Никто ее не контролирует. Работа с поставщиком идет по договору, оплата в конце месяца. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 16:27 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
БизонСумма в накладной увеличивает наш долг поставщику Ой ли? Я бы все же "плясал" от счета-фактуры. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 16:36 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Сергей Васкецов БизонСумма в накладной увеличивает наш долг поставщику Ой ли? Я бы все же "плясал" от счета-фактуры. Нет счета-фактуры. Работа ведется в разрезе договора. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 16:42 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Бизон Сергей Васкецов БизонСумма в накладной увеличивает наш долг поставщику Ой ли? Я бы все же "плясал" от счета-фактуры. Нет счета-фактуры. Работа ведется в разрезе договора. Да в любом разрезе. Приходная накладная еще не свидетельствует, что именно столько надо заплатить. Договор - тем более. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 16:44 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
БизонПредлагаю разобраться на примере конкретной операции. Сидит оператор на складе, ему принесли приходную накладную. Вводит. Нажимает кнопку «ОК». Указанное количество товара соответственно увеличивает остатки на складе товара. Сумма в накладной увеличивает наш долг поставщику. На следующий день поставщик нашел ошибку, не по той цене отгрузил. Присылает замену. А может только в конце месяца. На цену товара плевать всем. Никто ее не контролирует. Работа с поставщиком идет по договору, оплата в конце месяца. Хороший пример. Если меняется цена товара, то она оформляется как минимум ДРУГОЙ ПАРТИЕЙ. А постащику отправляется претензия. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 16:47 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Сергей Васкецов Бизон Сергей Васкецов БизонСумма в накладной увеличивает наш долг поставщику Ой ли? Я бы все же "плясал" от счета-фактуры. Нет счета-фактуры. Работа ведется в разрезе договора. Да в любом разрезе. Приходная накладная еще не свидетельствует, что именно столько надо заплатить. Договор - тем более. Тогда что свидетельствует. У меня есть два завода. Скажем так партнеры. Мой покупает продукцию другого, при этом сверку по документам бухгалтера любят делать в конце месяца. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 17:12 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
БизонТогда что свидетельствует Счет-фактура. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 17:21 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Все зациклились. Нет счета-фактуры.http://sql.ru/forum/images/happy.gif ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 17:41 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
БизонВсе зациклились. Нет счета-фактуры.http://sql.ru/forum/images/happy.gif Книги покупок и продаж оформляют? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 17:43 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Оформляют. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 17:47 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
БизонОформляют. Значит есть счета-фактуры. Просто Вы о них не знаете. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 17:49 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Без счета-фактуры организация не имеет право приходовать товар на продажу, а может только взять на хранение до тех пор, пока не придет счет-факура ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 18:00 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Сергей Васкецов БизонОформляют. Значит есть счета-фактуры. Просто Вы о них не знаете. Специально сходил к главбуху. Нет счетов-фактура оплата по договорам. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 18:09 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Сергей Васкецов БизонТогда что свидетельствует Счет-фактура. Вынужден Вас разочаровать, но счет-фактура ни о чем не свидетельствует , посольку служит только обоснованием перед фискальными органами для предъявления суммы НДС к вычету. А вот как-раз накладная, подписанная обеими сторонами, свидетельствует о переходе права собственности и возникновении задолженности. Вы, таким образом, попали в зависимость от бухгалтеров, которые для прикрытия собственных интересов требует счет - фаткры, но реально они нужны только самим бухгалтерам . ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 18:13 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Сергей Васкецов БизонОформляют. Значит есть счета-фактуры. Просто Вы о них не знаете. Да успокойтесь Вы со своими счетами фактурами. Без ТОРГ-12 у вас зачет по ним могут не признать. Так что накладная ой как о чем говорит. А если уж посмотреть последнюю судебную практику то у вас еще и ТТН попросить вправе. А Вы заладили про счет-фактуру. А на упрощенке и вмененке она вообще нафиг не нужна и что дальше ? А вот оплата по договорам это конечно до первого случая. Знавал я одну фирмочку писали в основании оплата по договору. Им штраф такой наложили - сколько они не видели за все время существования :) Выяснилось что в основании должен быть номер первичного документа. Если по договору - то номер счета как минимум. И сумма по каждому конкретном счету если по нескольким счетам. Если платеж авансовый все равно лучше счет попросить. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 18:22 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
scrafm +1 БизонПредлагаю разобраться на примере конкретной операции. Сидит оператор на складе, ему принесли приходную накладную. Вводит. Нажимает кнопку «ОК». Указанное количество товара соответственно увеличивает остатки на складе товара. Сумма в накладной увеличивает наш долг поставщику. На следующий день поставщик нашел ошибку, не по той цене отгрузил. Присылает замену. А может только в конце месяца. На цену товара плевать всем. Никто ее не контролирует. Работа с поставщиком идет по договору, оплата в конце месяца. :) Думаю что в курсе контекста вопросов. Тут, похоже, большинство представлено переквалификантами от фискальных органов. Ежли есть желание пообщаться по существу, стучитесь в асю 194144279; ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2007, 03:05 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
vbg75А вот как-раз накладная, подписанная обеими сторонами, свидетельствует о переходе права собственности и возникновении задолженности. Вы, таким образом, попали в зависимость от бухгалтеров Давайте я попытаюсь объяснить: а) что Вы не во всем правы; б) почему я написал про счета-фактуры; в) как у нас это сделано. Переход права собственности (ППС) никакого отношения к приходу на склад не имеет и определяется исключительно условиями договора. Может быть ситуация, что ППС осуществляется по факту прохождения оплаты и еще миллион других ситуаций, в которых ППС происходит как ДО прихода на склад, так и ПОСЛЕ прихода на склад. Я написал про счета-фактуры человеку по той причине, что он хотел уменьшить вероятность ошибок в документах, на основании которых формируется стоимость приходной партии. Счет-фактура в его случае (закупка) выставляется поставщиком в течение 5 дней и вероятность ошибки в нем уж никак не больше, чем в приходнике. В ситуации Бизона не описаны моменты, что счет-фактура не выставляется, их не так и много (смотрим НК и соответствующее постановление пр-ва). Сказки про то, что счета-фактуры отсутствуют в случае купли-продажи между заводами, как раз таки стоит рассказать фискалам. А желание считать задолженность по договорам вызывает у меня откровенное недоумение. Договор - слишком абстрактный документ, чтобы можно было его таким образом учитывать. Вполне возможно, что под договором у Бизона кроется конкретный заказ или даже счет, но суть от этого не меняется. "Собирать" задолженность в исполнении и оплате в разрезе договоров можно замечательно, но оплачивать в системе именно договора, а не их дочерние документы, скажем так, весьма недальновидное решение, которое может работать крайне редко. У нас в системе реализован отдельный документ "Акт ППС", который может быть в различных местах в цепочках документов с участием приходных документов склада и налоговых документов (другие здесь не интересны). То есть, ППС отделен и от движения по складам, и он счетов-фактур. Это позволяет учитывать любые тонкости в ППС, вплоть до отражения в учетной стоимости ТМЦ на складе таких затрат, которые приняты к учету после оприходования конкретной партии. С услугами тоже очень сильно помогает. В принципе, если в родительском договоре или заказе четко определен порядок ППС, ничто не мешает генерить АППС автоматически по наступлению условия ППС. Оплатить (в смысле сопоставления платежа любой природы с документом в системе) складской документ у нас невозможно в принципе. И вообще в складских документах (документах, которые отражают движение по складу) суммам делать по большому счету нечего (здесь предпочел бы эту тему не развивать, где-то вроде бы я писал уже об этом). Однако, автору я бы не рекомендовал использовать такой подход (с отдельным АППС), а ограничиться простым решением со счетами-фактурами (ну или корректировать не сами приходные документы, а стоимость на складе некими отдельными дочерними документами на основании полученных счетов-фактур как развитие данной мысли). ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2007, 10:01 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
PiterBestБез ТОРГ-12 у вас зачет по ним могут не признать. Ага. И без взятки проверяющим тоже. Такие ситуации мне неинтересны. По существу я ответил на пост vbg75. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2007, 10:03 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Сергей Васкецов Предложеный Вами алгоритм, очень интересен. Но тупые бухи боюсь не поймут. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2007, 14:00 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
To Бизон >Вы предлагаете использовать только одно состояние документа и после его утверждения не >менять. Да какая разница, сколько состояний. Я на практике применяю 2 - проведен - не проведен. Их достаточно именно для учетных документов. Есть еще информационные документы, которые не нуждаются в проведении, но состояние которых меняется триггерами в зависимости от нужных событий, происходящих в базе данных. Но приведенный мной выше принцип позволяет ОЧЕНЬ легко, как по объему кода, так и по скорости работы, делать в системе любое нужное количество состояний документа, и в зависимости от них - запрещать-разрешать-делать-откатывать какие-либо действия. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2007, 14:06 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
БизонПредложеный Вами алгоритм, очень интересен. Но тупые бухи боюсь не поймут. понимаю без проблем. Я тоже использую ППС ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2007, 14:15 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
БизонПредложеный Вами алгоритм, очень интересен. Но тупые бухи боюсь не поймут. Если Вы про "корректировать не сами приходные документы, а стоимость на складе некими отдельными дочерними документами на основании полученных счетов-фактур", то все довольно просто реализуется. 1. Приходный документ вводится "как есть". Утверждается. 2. При получении некоторых документов, свидетельствующих о том, что в документе есть "лажа" любого рода, создается некий документ (назовем его "Расценкой"), в котором с одной стороны указывается исходный документ склада, который надо скорректировать, а с другой - все новые изменения (неважно, из новой версии приходника или из сч-ф). Естественно, связь должна быть построчно, чтобы можно было понять, что чем меняется. В принципе, можно вводить как изменения, так и "новую версию" документа, от этого зависит только алгоритм утверждения расценки (в любом случае, по картотеке в результате расценки должны двигаться только изменения приходника, и за дату расценки). В общем случае один документ склада может так расцениваться много раз. 3. Проводки по расценке похожи на проводки по документам склада, хотя, можно и через отклонения работать, тут вариантов много самых разных. 4. Если документ склада есть хотя бы в одной расценке, его нельзя разутверждать. 5. Развитием этой функциональности можно расценивать любые приходники любыми затратами, в том числе и транспортными от РЖД, возникающими в конце месяца. 6. Данная функциональность у бухов обычно не вызывает непонимания. Логика до невозможности простая - надо для документа ввести новую версию и утвердить это изменение. Если Вы про отдельный АППС - с бухами будет гарантированная драка, когда мы это вводили (а это было перед принятием 25-й главы НК), было много недовольных. Довольно быстро все поумолкли и закайфовали, ибо все прозрачно, что принято, что в пути, какая задолженность и перед кем. Одна проблема - в зависимости от специфики работы не всегда могут однозначно выбрать, по какому алгоритму собирать книги покупок и продаж, ибо вариантов в такой схеме минимум 6, а думать в бухгалтерии не всегда поощряется. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2007, 14:19 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Ткните ссылкой где можно почитать болле подробно о механизме ППС ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2007, 14:21 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
БизонТкните ссылкой Не готов дать ссылку, просто не знаю такой, все в голове и рабочих документах. Может Валерий подсобит? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2007, 14:25 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
БизонТкните ссылкой где можно почитать болле подробно о механизме ППС В учетной политике организации прописываются эти понятия и если главбух про них не знает, то он не главбух, потому что учетную политику формирует главбух и директор на год и в течении года не имеют право ее менять. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2007, 14:26 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
БизонПредложеный Вами алгоритм, очень интересен. Но тупые бухи боюсь не поймут.Это до первого арбитража, там законы хорошо объясняют, на примерах:) 2 iscrafm Применяете ППС в смысле регистрируете ППС как отдельное событие на основании имеющихся первичных документов или еще и акт специальный применяете? Если спец акт, то кто его сочиняет и подписывает? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2007, 14:27 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
С главбухом у меня тяжко. Дальше чем 1с увидеть не может. Все движение сведено к бух. проводкам и привязано к плану счетов. Много нужной информации теряется в процессе обработки. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2007, 14:31 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
БизонС главбухом у меня тяжко Значит надо выходить на финдира. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2007, 14:35 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Сергей Васкецов БизонС главбухом у меня тяжко Значит надо выходить на финдира. Ясень пень вышел. Слава богу не отсебятеной занимаюсь. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2007, 14:50 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Бизон Сергей Васкецов БизонС главбухом у меня тяжко Значит надо выходить на финдира. Ясень пень вышел. Слава богу не отсебятеной занимаюсь. Тогда не понятно, что за проблемы могут быть с главбухом. Встречал ситуации, когда главбух просто динамила некоторые решения или отвечала типа "это все так сложно, я-то знаю, потому нам не надо это делать". После вмешательства руководства и "последнего предупреждения" дело сдвигалось. Руководство обычно не любит извиняться за бухгалтерию дважды. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2007, 14:55 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
ModelR 2 iscrafm Применяете ППС в смысле регистрируете ППС как отдельное событие на основании имеющихся первичных документов или еще и акт специальный применяете? Если спец акт, то кто его сочиняет и подписывает? один из вариантов реализации..., вкратце в договоре указывается момент ППС, на станции грузоотправителя, грузополучателя и т.п. все что отправляется ЖД, фиксируется в каких вагонах, номера ЖД накладных,груз и т.д. МПС дает данные о прибытии вагонов на станции, эти данные загружаются в систему, обрабатываются и автоматом формируется пакет ТТН, дата которой определяет момент ППС. Эти ТТН (ППС) являются основанием для бухгалтерии по формированию проводок. С перевозчиками периодически составляется АКТ, его не сочиняют, есть оговоренная форма, он из системы только данными наполняется. в другом варианте... где доставка морем... руками специальные документы отгрузки с датой, которая определяется условиями поставки (CIF,CIP,CPT и прочие) ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2007, 17:12 |
|
|
start [/forum/topic.php?all=1&fid=33&tid=1548931]: |
0ms |
get settings: |
8ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
40ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
95ms |
get tp. blocked users: |
2ms |
others: | 272ms |
total: | 447ms |
0 / 0 |