Добавить поле поставщика в движение по складу

[GoogleCodeExporter]

Скачал проект. Очень понравилось. Не смог 
найти одну вещь. Информацию о поставщиках 
товаров. Чтобы детально какой поставщик, 
что когда сколько принес. Сколько перед 
поставщиком магазин имеет задолженности.

Original issue reported on code.google.com by muratov....@gmail.com on 11 Jan 2012 at 4:48

[GoogleCodeExporter]

В концепции POS системы не предполагается 
вести учёт кредиторской задолженности, это 
делается уже в ERP. Хотя в некоторых 
доработанных вариантах Openbravo POS я видел 
добавляют справочник поставщиков, хотя по 
логике должен быть единый справочник 
контрагентов, которые одновременно могут 
быть и поставщиками и покупателями. Если 
есть интерес в реализации такого 
функционала можем обсудить, как это 
сделать в Openbravo POS.

Original comment by svinin...@gmail.com on 11 Jan 2012 at 6:59

• Changed title: Добавить поле поставщика в движение по складу
• Added labels: Component-Logic, Performance, Priority-Medium, Type-Enhancement

[GoogleCodeExporter]

Вот как это может выглядеть.

Original comment by svinin...@gmail.com on 11 Jan 2012 at 5:48

Attachments:

• OpenbravoPOS-StockSupplier-1.png

[GoogleCodeExporter]

Что-то мне подсказывает, что пора делать 
свою ERP к OB...

Original comment by dmg...@gmail.com on 12 Jan 2012 at 11:16

[GoogleCodeExporter]

svinin...@gmail.com. Если есть ссылка на такой 
проект или тот который надо доделать 
скиньте ссылку попробую доделать. Буду 
очень признателен. Просто самому все 
сначала делать не хочется))).

Original comment by muratov....@gmail.com on 13 Jan 2012 at 5:47

[GoogleCodeExporter]

Скриншот я сделал из моего прототипа 
интерфейса для кода на основе Openbravo POS ru. 
Сейчас у меня есть заказчик, который готов 
за разработку этого функционала заплатить. 
Так что если всё срастётся и я получу 
оплату от заказчика, то добавлю справочник 
поставщиков и в наш проект. Там только 
придётся вносить изменения в базу данных, 
так что совместимости с оригинальным кодом 
Openbravo POS не будет.

Original comment by svinin...@gmail.com on 13 Jan 2012 at 6:23

• Changed state: Work

[GoogleCodeExporter]

Мне тоже придется начать тогда над этим 
работать. Интересно посмотреть что 
получится у вас. Я тоже работаю над вашим 
проектом.

Original comment by muratov....@gmail.com on 13 Jan 2012 at 8:54

[GoogleCodeExporter]

Сейчас думал над необходимостью наличия 
учёта поставщиков в POS системе, то есть на 
кассе. Если возможна ситуация когда 
поставщик может получить деньги за 
поставленный товар на кассе, то на кассе 
обязательно нужно знать задолженность 
перед поставщиками, то есть нужно вводить 
учёт по кредиту(сейчас в Openbravo POS есть учёт 
по дебету для покупателей).

Посмотрел в проекте OpenPOS, там сделан дубляж 
функционала и логики работы с справочником 
CUSTOMERS, для чего добавлен новый справочник 
SUPPLIERS. При этом платежи поставщикам как раз 
и не работают. Вот мой вариант изменений в 
структуре база данных:

1) CUSTOMERS переименовать в BUSINESS_PARTNERS 
2) добавить два логических поля 
BUSINESS_PARTNERS.CUSTOMER и BUSINESS_PARTNERS.SUPPLIER, т.е. 
контрагенты могут выступать в одной из или 
сразу в двух ролях
3) добавить поле BUSINESS_PARTNERS.CURCREDIT для учёта 
кредиторской задолженности предприятия 
перед поставщиком, для учёта дебиторской 
задолженности покупателя перед 
предприятием остаётся поле BUSINESS_PARTNERS.CURDEBT

Если Вам такой вариант подходит давайте в 
дальнейшей работе над этой задачей 
объединим усилия.

Original comment by svinin...@gmail.com on 13 Jan 2012 at 12:24

[GoogleCodeExporter]

Идея отличная, но такой расширенный 
функционал для меня пока лишний. Учет 
поставщиков осуществляется не на кассе в 
моем случаи. Если придерживаться вашей 
идеи, то придется подкорректировать все 
модули для работы с клиентами, который 
сейчас реализован. Или нет?

Original comment by muratov....@gmail.com on 13 Jan 2012 at 4:48

[GoogleCodeExporter]

Вот так я вижу структуру таблицы для 
хранения связи много ко много между 
таблицами PRODUCTS и BUSINESS_PARTNERS(вместо 
переименования пока можете 
поэкспериментировать с таблицей CUSTOMERS)

CREATE TABLE PRODUCTS_SUPPLIERS(
    ID VARCHAR(255) NOT NULL,
    PRODUCT VARCHAR(255) NOT NULL,
    BUSINESS_PARTNER VARCHAR(255) NOT NULL,
    PRIMARY KEY (ID),
    CONSTRAINT PRODUCTS_SUP_FK_1 FOREIGN KEY (PRODUCT) REFERENCES PRODUCTS(ID),
    CONSTRAINT PRODUCTS_SUP_FK_2 FOREIGN KEY (BUSINESS_PARTNER) REFERENCES BUSINESS_PARTNERS(ID)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE UNIQUE INDEX PSUP_INX_PROD ON PRODUCTS_SUPPLIERS(PRODUCT, 
BUSINESS_PARTNER);

Original comment by svinin...@gmail.com on 19 Jan 2012 at 2:22

[GoogleCodeExporter]

Ja ochen` zainteresovan v atot modul` - slezhu vnimatelno kak tut razvivaetsa 
tema. 

Original comment by sergiu.c...@gmail.com on 10 Apr 2012 at 1:20

[GoogleCodeExporter]

Так чем закончилось? есть ли готовый 
модуль? можно обсудить стоимость и опалту?

Original comment by vvsch...@gmail.com on 24 Jul 2013 at 9:12

[GoogleCodeExporter]

Ничем. Я упёрся в то, что для склада надо 
делать нормальные приходные накладные по 
типу существующих чеков, где хранить 
полностью структур приходных документов. А 
на это  у меня времени к сожалению так и не 
нашлось.

Original comment by svinin...@gmail.com on 30 Jul 2013 at 8:17