Логика программы для кассы и склада: нужны советы

← →
miwa (forgot pw) (2006-04-17 09:21) [0]

Хочу делать примерно так:

Справочник контрагентов
- ИД, наименование, контакты, реквизиты...
Справочник товаров
- ИД, наименование, код, ед.измерения...
Справочник документов
- ИД, наименование
Справочник способов оплаты
- ИД, наименование

Накладные (приход, расход, внутренние перемещения)
- ИД, номер, контрагент, сумма, НДС, количество...
- состав: ИД, ИД товара, ИД накладной, цена, НДС, количество
Товарные чеки
- ИД, номер, сумма, НДС, количество, % скидки
- состав: ИД, ИД товара, ИД чека, цена продажи, цена на текущий момент (чтобы была возможность определять величину скидки), количество, НДС

Ревизия
- ИД, номер, дата, кто проводит...
- состав: ИД товара, количество на момент ревизии, цена на момент ревизии
- результаты: ИД товара, разница между фактом и базой

Движение документов
- ИД, ИД документа, сумма, дата, НДС, контрагент
Движение товара
- ИД, ИД товара, дата, количество, цена, НДС, ИД документа

Так получилось, что заказчиков сразу несколько: небольшие магазины, но, как на подбор, все со своей спецификой - детский (работающий праткически только с наличкой); канцелярский (работающий в основном по безналу, но и с наличкой имеющий дело); садоводческий (работающий и так и эдак, да еще часть ассортимента - химудобрения да семена - имеют срок хранения; иногда продает мелкий опт) ну и компьютерный до кучи (покупающий десяток комплектующих, которые потом продаются в виде одного изделия, которое, возможно, надо ремонтировать, заменять комплектующие и т.д.). И, честно говоря, очень хочется написать программу, которая работала бы у всех. Собственно, вопросс - стоит ли? Какие плюсы-минусы, кроме очевидных, как то легче сопровождать, но тяжелее реализовать? Настолько ли легче сопровождение, чтобы заморачиваться с реализацией?

Дальше. В одного из клиентов зарегистрировано два ЧП: один с НДС, второй работат по упрощенному налогообложению (Украина; есть у нас такая фишка в законодательстве). У другого - вообще три. Правда, все три работают по упрощенной схеме.
Собственно второй вопросс - как разделять этих ЧП? Вести для каждого отдельную базу, справочники которых синхронизировать? Или может ввести в документы и таблицу движения кроме контрагента "внешнего" еще и контрагента "внутреннего"? Или есть какие-то более удобные решения?

Ну и еще интересуют советы по поводу рассчета количества остатков и их себестоимости. Насколько я понимаю, "партионный учет" - это когда товары с разной датой прихода маркируются разными кодами и, соответственно, в любой момент времени можно узнать проданное количество товара, его сумму, когда он поступил и т.д. Видимый минус этой красоты (для меня) - необходимость лепить свою этикетку на каждую упаковку товара. А есть еще товары, которые не очень-то и пакуются. Семена картошки, например. Так что опять суть вопросса - стоит ли такой учет того, чтобы им заниматся? Или в кассовых программах вообще все совсем иначе делается? Ну и дополнительно - списывание товаров по FIFO здесь ругают, среднюю себестоимость тоже не особо жалуют. Какое из этих зол меньше?

Ну и с учетом всего вышенаписанного - с большой благодарностью почитаю ваши советы как насчет структуры базы, так и "о жизни в целом" :о)

← →
Johnmen © (2006-04-17 09:39) [1]

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

По теме.
>Справочник способов оплаты
Я бы не стал его заводить, ибо этих способов раз-два и обчёлся. И они постоянны и фиксированы, неизменна их совокупность.

← →
Sergey13 © (2006-04-17 09:53) [2]

>И, честно говоря, очень хочется написать программу, которая работала бы у всех
И желательно, наверное, за месяц-два. 8-)
Ну-ну. Желаю удачи.

>Видимый минус этой красоты (для меня) - необходимость лепить свою этикетку на каждую упаковку товара.
Странно, что ты разглядел только самый малюсенький минус.

← →
miwa (forgot pw) (2006-04-17 10:52) [3]

> Для профессионального обсуждения проблем ведения бухгалтерии
> и матучёта надо бы идти на специализированные сайты...
> Здесь же обсуждается программистская сторона дела.

Хм. Года два назад было немного иначе. Да и не претендую я на профессиональное обсуждение бухгалтерии. Меня как раз программистская сторона и интересует.

> >Справочник способов оплаты
> Я бы не стал его заводить, ибо этих способов раз-два и обчёлся.
> И они постоянны и фиксированы, неизменна их совокупность.

Наличный, безналичный, взаимозачет...
Что я пропустил?

> >И, честно говоря, очень хочется написать программу, которая
> работала бы у всех
> И желательно, наверное, за месяц-два. 8-)
> Ну-ну. Желаю удачи.

Спасибо :о)
Не, за месяц-два я надеюсь увидеть рабочий скелет, за три - что-то более-менее работающее. И это "более-менее" не претендует на уровень серьезных разработок - так, остатки в магазине посчитать, да заказ подсобить сформировать (утрирую, конечно).

> >Видимый минус этой красоты (для меня) - необходимость лепить
> свою этикетку на каждую упаковку товара.
> Странно, что ты разглядел только самый малюсенький минус.

А как насчет подсказать о других минусах?

← →
kilkennyCat © (2006-04-17 10:57) [4]

а разве необходимую конфигурацию для 1С сделать не проще?

← →
Sergey13 © (2006-04-17 11:10) [5]

>А как насчет подсказать о других минусах?
Ну, например, учитывать разные партии при расходе товара, когда в накладной может быть несколько строк с "одинаковым" товаром. Т.е. списывать с конкретной партии.

Для детского магазина (возможно) не нужен справочник товара, т.к. вряд ли там партионный учет. А для компьютерного наверное желателен справочник с указанием совместимости комплектующих. Для сроков хранения вообще - отдельная песня.
В общем сложно будет совместить бульдога с носорогом. Проще будет писАть разные проги, что не исключает заимствования части кода. Я бы посоветовал сначала изучить подробно все условия всех магазинов и вычленить совпадения и различия. Что-то можно в настройку вынести, а под что-то свои модули ваять.

kaif тут с год назад вроде предлагал свое детище (Алегро вроде называется) - конструктор для быстрой разработки подобных вещей. По местным отзывам - вроде неплохо у него получилось. Поищи. Правда там за деньги.

← →
Mike Kouzmine © (2006-04-17 11:31) [6]

Начинать эту историю не зная бухгалтерии бесполезно.

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

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

← →
miwa (forgot pw) (2006-04-17 11:32) [7]

> а разве необходимую конфигурацию для 1С сделать не проще?

А разве здесь не форум программистов? ;о)
Кроме того, 1С еще надо уметь конфигурировать.

> >А как насчет подсказать о других минусах?
> Ну, например, учитывать разные партии при расходе товара,
> когда в накладной может быть несколько строк с "одинаковым"
> товаром. Т.е. списывать с конкретной партии.

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

← →
Mike Kouzmine © (2006-04-17 11:33) [8]

А вообще, велосипед давно изобретен. 30000 руб за сетевую версию. Назвние любое.

← →
Sergey13 © (2006-04-17 11:41) [9]

2[7] miwa (forgot pw) (17.04.06 11:32)
> и как раз это дает возможность безпроблемного списывания товара с конкретной партии.
Да проблем нет - только надо это все учитывать. Не просто списать 100 кг гвоздей, а 50кг от Иванова, 30 от Петрова и 20 от Сидорова. По разным ценам. Или по одной, но тогда разная прибыль и т.д. и т.п.
Кроме того не все на складе упаковано в отдельную тару с прилепленными этикетками. Те же гвозди вполне могут и в одном ящике лежать. Разбирайся потом. 8-)

← →
miwa (forgot pw) (2006-04-17 11:46) [10]

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

А кто такой "раздельный учет" и како отношение он имеет к детским вещам?

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

Везде применяется система единого налога.

> А если вышеуказанного не надо и программа будет типа калькулятор,
> то ничего сложного нет. Все, что ты предложил - подходит.
> Только вряд ли такая программа будет нужна.

Вышеуказанного - это "настоящей" бухгалтерии? Так говорю же: всюду используется система единого налогообложения: в таком случае ЧП платит фиксированную сумму налога вне зависимости от внешних факторов и полноценная бухгалтерия его не интересует.
В свете написанного - что значат ваши слова Все, что ты предложил - подходит.? Насчет структуры базы? А как тогда с унификацией (хотя вижу - не рекомендуют), несколькими ЧП в одном магазине, остатками? В смысле, что посоветуете?

← →
VICTOR_ (2006-04-17 11:52) [11]

Рекомендую
1.Приобрести литературу по основам бухгалтерского учета.
Напр.Ткаченко. Бухгалтерський фінансовий облік на підприємствах України.
2.Детально разобраться в принципах организации базы и механизмов работы бухгалтерских программ.
3.Четко поянить заказчикам, что за свои деньги они получат то-то и то-то, а не больше или так как это должно было быть. Лучше всего описать функциональность в письменном виде в виде Технического задания и чтобы это подписал заказчик.
4.Для самостоятельной разработки - составить бизнес-план проекта, четко продумать источники финансирования и т.д.
5.Возвратиться к вопросу о структуре базы и бизнес-логике работы только после четкого осмысления п.1.-4.
P.S.Лучший вариант в данном случае - взять готовую систему учета и, возможно, ее адаптировать под Ваших заказчиков. Этот вариант будет наиболее оптимален по затратам времени и расходам для заказчиков, а также по затратам времени и доходам для Вас.

← →
boriskb © (2006-04-17 12:02) [12]

VICTOR_ (17.04.06 11:52) [11]
Лучший вариант в данном случае - взять готовую систему учета и, возможно, ее адаптировать под Ваших заказчиков

Вне всякого сомнения.

Наличный, безналичный, взаимозачет...
Что я пропустил?

Кроме этого оплата делится на предоплату, оплату по факту (в день отгрузки) и пост.оплату.
От этого может зависить сумма скидки/надбавки, т.к. все хотят получить предоплату налом, чем постоплату путем взаиморасчета.

Это только один нюанс.
А если в магазине захотят сделать скидку от суммы покупки или сезонную скидку или систему дисконтных скидок?

"партионный учет" - это когда товары с разной датой прихода маркируются разными кодами

Я бы на месте директора магазина руки за такое оторвал.
Как из разных кодов собирать отчетность?

> "партионный учет" - это когда товары с разной датой прихода
> маркируются разными кодами

Луна всё дальше Земля всё ближе.
Партионный учёт - это когда организуется дополнительный справочник учитывающие поступление товаров по партиям. Они имеют разные цены закупки и сроки годности. Что и отражается в документах при различных движениях ТМЦ.

ЗЫ :Кто работал с .934 с его вечным "не распредилилось по партиям" тот поймёт сложность проблемы :-)

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

> Потом директорам магазинов приспичит отчетность в налоговую
> сдавать...

а причём здесь налоговые отчёты и складской учёт?????
в налоговую ты баланс здаёшь, а не приход/расход по складу. Они ёкнуться твою базу проверять.

А какой смысл в системе, если она не формирует баланс?

Логика программы для кассы и склада: нужны советы Найти похожие ветки