This project is read-only.

Compied the code, what next

Sep 18, 2012 at 11:06 PM

Yes, I do want to contribute. However, mind you I am not a c# programmer (and I do not have formal education in prgramming).

I have joined this project to gain experience in c# coding.

Is ther any particular reason why you want to start with address? I was thinking of inventory.

(which reminds me, can you add the sql script as a part of project download? so that we will get the latest version every time we sync the project.)

1) On the database side: I am not very happy with Parts prefix. Parts indicates that it is going ot be 'part' of manufacturing. which is in theory not compatible with trading companies :) We can probably use item prefix instead. Let us also refactor the existing table, somehting like onHold, onHoldDate, onHoldReasonId can be shifted to a separate table.

2) On the code side, I can see XERP.Domain this should be moved to XERP.Domain.System. Once this is done I think we can add XERP.DOMAIN.Vendor XERP.DOMAIN.Customer etc. Let me know your thoughts.

Over all my comment would be (on app side) let us finalize our customer. Whether intially we are targeting small or mid-tier or large companies. Then let us finalize the featuers and then start coding the features.

 

What do you say? Perhaps a conf call ?

 

Sep 19, 2012 at 12:31 AM
Edited Sep 19, 2012 at 1:10 AM

I wanted to start with Addresses because it is very simple Module...  When  I say module I mean specific screen...  The inventory that you speak of will end up being lots of screens...  Their may be one DAL/Service and domain project that services the inventories but their will be many client side MVVM UI's project that will serve up the inventory requirements...

The reason we modularize is so much is that it helps performance.  If you stick the whole data base in one huge entity it is slow and turns into a tangled mess.  If you break it up and only include the required tables that are pertitent to the screen or screens you are creating it is much eaiser to work with...

The reason I say to start with Addresses is it is very easy low level Maintanance screen that will require 1 DAL project, 1 Service project as well as 1 domain project and of course 3 client project to present the UI... and the other two for the Code drop down and type drop down maintenance screens as every Object in XERP always gets a type and a code just a couple of jack knive descriptors that can be used to identify and classify the object...

The simple creation of Address from soup to nut in essence will serve as a way for someone to run through the process of creating a XERP UI from soup to nut...  As well it is and will be required eventually...

XERP.Domain is a shared domain project that is inherited by all XERP.Domain.Object name...  so using the Address as an example we would have a domain project called XERP.Domain.AddressDomain...  XERP.Domain is then shared among all the domain projects to maintain global method and properties...  so XERP.Domain.AddressDomain would use the XERP.Domain to get shared required info to communicate with the XERP Server section among other Utility type things that all Domain projects would require...

XERP needs to remain very general and can not be made for any one specific customer...  The general product should be very vanilla then when a targeted company comes along it should and can be very easily retro fitted for specificity to the company...

#1 comment is interesting Part is as you said a manufactured part, or a purchased part, or a raw material as well parts can have Recipes which is essence would pe the parts Method of Manufacturing and Bill of Material... for trading companies this system would not work very well and I think that Part will identify with 80% of the market space and I think over complicating it to adhere for trading companies may be scope creep...

I really enjoyed your comments and while you may not be a Coder it does sound like you really know about ERP...

Right now XERP is made of a party of two Oscar and myself the other contributors listed are part of the old shool build of XERP that was based on XAF and have not contributed any thing to the current build...

Oscar found XAF to be to propietary so we started to rebuild it from scratch...

The tables in their current state are no where near complete and I am struggling in my off hours as I have a real job to get XERP to the bare minimum where you have at least the bare essentials of User maintenance, Menu Maintenance, Security Group Maintenance, Menu Display, Log In, Menu securities...

I have not though much about Parts, Order, quote, sheduling, accounting, ect as I have been so busy just getting a repeatable pattern developed and then using it to create the few modules I have thus far...

But eventually once we have the basics build we will really have to think about the tables and tieing it all together and your input thus far has impressed me...

Perhaps you could be a main contributor as to vision of table construct and what not; and as well testing the UI's as really all to down stream UI's we build will function in basically the same way...

anyways thanx for your input... 

In the meantime I would just puts around with it as is... If you can run it and log in then should be able to hit some of the company folder modules...

i.e.  system User, Security groups, Company  these screens are fully functional... you can add update and delete on these screens and poke around and get a general theme for XERP UI...  any input as to this sucks are that sucks will go a long ways...

I am getting very close to blessing the overall design and if we miss something and create a crap load of UI's then we will have to go back in to each of them and add to each of them...  so I am attempting to get a good base to clone from as we make more UI's...

by the way your name dumbass is not very profesional while i am not the most profesional guy in the world I would say that your name does not help to promote a serious investor if one was ever to come along to pull XERP from the back door dungeons and in to the main board room...

One other comment you had about adding the SQL Script...  It is on my todo list to add an install feature and that would include installing the db... in the meantime I have the db in the download section but I could put it in the documentation folder as well so we can track changes that is an excelent idea i will start doing that...

Sep 19, 2012 at 1:55 AM

ok, I will change my name from dumbass to something more professional. I did not know that we were planning to look for some investor in future :) I thought this was just fun project.

anyway.. I see address as a framework. The framework will have some forms which will morph depending on the caller for e.g. customer/vendor. This is why I was thinking about writing some other modules first. Possible we can start with customer or vendor module.

As to parts :) even manufacturing companies have non-part related requirements such as subcontracting services which cannot modelled as parts. So item will be a better prefix. We really do not have to do much to enable trading organization. A LOT of trading org are a subset of manufacturing functionality.

I will start some basic datamodelling and email it to you. The 'notes' field on the item should also be a framework. Notes will also be a generic functionality and the notes form should morph depending on the caller (against item, customer, vendor, sales order, purchase order etc.) Once we dump notes into a separate functionality then notes can be moved to a different field and can be made much larger (which is usually required).

(By the way I am a coder as well, it is just that I code in an arcane language with its own environment. I was a procurement manager before I started coding)

Sep 19, 2012 at 2:32 PM

Data modeling sounds good you can email to me directly at xerp.net@gmail.com...

I think it would be very beneficual for you to create the Address Maintenance Projects...  Trust me you will want to start with that one as it will help you to understand XERP modulation...

Creating the Address Maintenance Screen will give you the foundation of how XERP works and is modulated...  After you build it then you can move on to Customer, Vendor, ect... 

The current documentation I have clones from Company Maintenance Projects(Company has only the one primary key of CompanyID)... so when I used it to create the Security Groups Projects I found that it did not specify in the query for CompanyID + AddressID so what we will want to do is as we create the Address Maintenance Project we will want to revamp the How To Document to use Address as the clone source for project creation as it will require the dual primary key of AddressID and CompanyID...

We need to walk before we run here we have to make sure we have a good document that allows for the creation of XERP maintenance screens from soup to nut...

This repeatable pattern will be the strongest point for XERP and once you create one you will truly understand the modulation of XERP and how each targeted functionality is encapsulated in to its own set of projects...

So being a coder and especaill not a C# coder it will be an excelent chance for you to use the document to create The Address Maintenance UI. 

This will test to see if another developer can use the document to create a set of Set of XERP maintenance screens...

So if you are interested The document is included in the documentation folder and is fairly thorough with a pretty good step by step...

it is called HowToCreateXERPServerToClientModule.doc

 

Doing this will be imperative as it will give you the insight required to understand the pattern of XERP...  After doing this then you will have a firm footing to contribute...