[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

pl.comp.programming

aplikacja do obslugi sklepu

Marcin Cylke

5/26/2007 9:10:00 PM

Witam

Zamierzam napisac aplikacje obslugujaca sklep. Zapotrzebowanie na
funkcjonalnosc to:
- informacje na temat asortymentu sklepu (z pokrewnymi informacjami)
- sprzedaz z wystawieniem faktur
- przeprowadzanie remanentów
- rejestrowanie zakupów przeprowadzanych na firme
- i pewnie jakies jeszcze inne ale drobne.

O ile modul dotyczacy zarzadzania asortymentem nie jest niczym
szczególnym, to zastanawia mnie ta cala czesc ksiegowa. Czy do pisania
tego typu aplikacji trzeba miec jakies certyfikaty itp? Czy rózne
instytucje to akceptuja pózniej (dane pochodzace z takiego programu)?

Czy pisanie takie modulu ksiegowego z wyzej wymieniona funkcjonalnoscia
nie jest porywaniem sie z motyka na slonce? Nie ma tam byc rzeczy
takich jak drugi "kasa przyjmie", czy bardziej zaawansowane elementy
ksiegowe.

Prosilbym o jakies opinie w tym temacie.

Pozdrawiam
Marcin
3 Answers

Jacek Czerwinski

5/26/2007 9:37:00 PM

0

Dnia Sat, 26 May 2007 23:09:52 +0200, Marcin Cylke napisa3(a):

> Witam
>
> Zamierzam napisaa aplikacje obs3uguj?c? sklep. Zapotrzebowanie na
> funkcjonalno?a to:
> - informacje na temat asortymentu sklepu (z pokrewnymi informacjami)
> - sprzeda? z wystawieniem faktur
> - przeprowadzanie remanentów
> - rejestrowanie zakupów przeprowadzanych na firme
> - i pewnie jakie? jeszcze inne ale drobne.
>
> O ile modu3 dotycz?cy zarz?dzania asortymentem nie jest niczym
> szczególnym, to zastanawia mnie ta ca3a cze?a ksiegowa.

Pomy?l o (zaledwie) interfejsie/integracji do systemu F-K. Ze sprzeda?y nie
jest zbyt trudne, te transakcje s? do?a schematyczne. Zakup ju? zawiera
niekiedy pewn? finezje, i rzadziej jest automatyzowany.
Do jakich systemów F-K?
Rozejrea sie po (potencjalnych/pierwszych) klientach.

Czy piszesz o sklepie www?
A w ogóle, czesto NIE emituje sie oficjalnych faktur VAT ze sklepu www,
lecz ze stacjonarnego systemu. Zw3aszcza paragon jest prawnie trudnym
dokumentem.

Stworzenie pe3nego uznanego F-K opó?ni ci robote o jakie? 3-4 lata ;-)
Tzn za 3-4 lata przekonasz ksiegowych do zakupu twojego systemu.

Marcin Cylke

5/27/2007 7:19:00 AM

0

On Sat, 26 May 2007 23:36:32 +0200
Jacek Czerwinski <x@y.z.pl> wrote:

> Pomysl o (zaledwie) interfejsie/integracji do systemu F-K. Ze
> sprzedazy nie jest zbyt trudne, te transakcje sa dosc schematyczne.
> Zakup juz zawiera niekiedy pewna finezje, i rzadziej jest
> automatyzowany. Do jakich systemów F-K?
> Rozejrec sie po (potencjalnych/pierwszych) klientach.

Nie myslalem o integracji, bo nie znam nic takiego co juz istnieje i by
sie nadalo. A zarazem bylaby mozliwosc integracji tego. Jesli jest, to
polec cos - w miare mozliwosci chodzi mi o rozwiazanie open source.

A jesli by pisac cos takiego samemu, to co nalezy do rzeczy ciezkich ze
wzgledu na prawo/niewygodnych w implementacji?

> Czy piszesz o sklepie www?
> A w ogóle, czesto NIE emituje sie oficjalnych faktur VAT ze sklepu
> www, lecz ze stacjonarnego systemu. Zwlaszcza paragon jest prawnie
> trudnym dokumentem.

Nie, ma to byc oprogramowanie dla normalnego sklepu. A jesli juz
piszesz o sklepie www, to czy jest to tak samo obwarowane prawnie jak
sprzedaz wysylkowa?

> Stworzenie pelnego uznanego F-K opózni ci robote o jakies 3-4 lata ;-)
> Tzn za 3-4 lata przekonasz ksiegowych do zakupu twojego systemu.

Czy te 3-4 lata to czas pisania aplikacji (z doprowadzeniem jej do
uzywalnosci przez dzial ksiegowy), czy moze kwestia przekonywania?

Pozdrawiam
Marcin

Jacek Czerwinski

5/27/2007 11:30:00 AM

0

Dnia Sun, 27 May 2007 09:18:51 +0200, Marcin Cylke napisa3(a):

> On Sat, 26 May 2007 23:36:32 +0200
> Jacek Czerwinski <x@y.z.pl> wrote:
>
>> Pomy?l o (zaledwie) interfejsie/integracji do systemu F-K. Ze
>> sprzeda?y nie jest zbyt trudne, te transakcje s? do?a schematyczne.
>> Zakup ju? zawiera niekiedy pewn? finezje, i rzadziej jest
>> automatyzowany. Do jakich systemów F-K?
>> Rozejrea sie po (potencjalnych/pierwszych) klientach.
>
> Nie my?la3em o integracji, bo nie znam nic takiego co ju? istnieje i by
> sie nada3o.
To masz problem: nie widz?c nic co sie w bran?y dzieje chcesz to zrobia.
W3a?ciwie tu powinein byc koniec rozmowy. Ewentualnie wynajmij bieg3ego
ksiegowego do projektu.

> A zarazem by3aby mo?liwo?a integracji tego. Je?li jest, to
> polea co?
Rozejrzyj sie sam w swoim ?rodowisku.

> - w miare mo?liwo?ci chodzi mi o rozwi?zanie open source.
OS nie znajdziesz (na rynek polsko-europejski; na ameryke moooo?e co? jest)
nawet gdyby by3o co? OS, to jest wedka a nie ryba - nie umiej?c 3owia ryb
itd.

>
> A je?li by pisaa co? takiego samemu,
po co 174-ta F-K????

> to co nale?y do rzeczy cie?kich ze
> wzgledu na prawo/niewygodnych w implementacji?
nawet jest jaka? elegancja w zrobieniu rdzenia F-K, jak na studiach. Ale
potem id? wyj?tki i dodatki.

> Nie, ma to bya oprogramowanie dla normalnego sklepu.
W czym jest specyfika tego sklepu ze trzerba pisaa ? I dlaczego klient ma
tobie cokolwiek zap3acia, je?li programy zaczynaj? sie od 100z3otych, a od
500 to ca3kiem rzetelne.

>> Stworzenie pe3nego uznanego F-K opó?ni ci robote o jakie? 3-4 lata ;-)
>> Tzn za 3-4 lata przekonasz ksiegowych do zakupu twojego systemu.
>
> Czy te 3-4 lata to czas pisania aplikacji (z doprowadzeniem jej do
> u?ywalno?ci przez dzia3 ksiegowy), czy mo?e kwestia przekonywania?

U?ywalno?ci, prze?ycie (w sensie ty i twoi kienci) 2 bilansów (a
przynajmniej jednego), obudowanie 'warto?ci? dodan?'.
Potem przekonanie, a dobry ksiegowy jest wymagaj?cy, ksiegowy "dzieciak"
we?mie co dasz - ale robiac dla niego wyko?lawisz sobie produkt.