LedgerSMB
The foundation for your business
Fork me on GitHub
[ledgersmb-users] Re: Adding parts
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ledgersmb-users] Re: Adding parts



> > fmiser wrote:

> > I don't need assemblies.  The old SQL-Ledger had troubles with
> > assemblies so I don't have them anymore.

> Erik wrote:
>
> Ok. That simplifies matters. I'll see what I can do in the
> coming days.

Okay!  Thanks!

> > Maybe I could use psql to fill in the table with everything
> > but "qty on hand" and "purchase price". Then use the existing
> > inventory update process.

> Well, the current import script imports "inventory" for existing
> "parts". Importing inventory means that it sets up the
> quantities and balance in the inventory account (for the parts
> specified) and sets up the desired COGS values.

I think you are saying that my idea of two-step would work.  That
is, use 
   COPY parts
   FROM 'file.csv' DELIMITER ',' CSV HEADER;

to fill in most of the information, followed by a run of the
inventory import script.

> > Then what about customers and vendors (contacts)?  Is there a
> > way to get 200 customers and 120 vendors in - again without
> > adding them one at a time?

> The existing import system doesn't have imports defined for
> customers and vendors. I can see why you would say that a
> straight CSV import into the tables might not be easy. I think
> it's actually not too much work with the following information:
> 
> * LedgerSMB differentiates between entities (legal entities and
> natural persons) and the roles they can have
> * Customers are entities with a customer role (vendors too)
> * To set up a customer, you need to set up a record in the
> following tables:
>   - "entity"
>   - "company" or "person" (entity_class doesn't really matter;
> you can select any -- it's not used in the system)
>   - "entity_credit_account", with a role "customer" in the
> entity_class
> 
> That's all there is to setting up a customer (or vendor).

That looks doable.  Not necessarily without risk of error,
though...  Hmm. Maybe a spreadsheet with one tab with all the
data, and other tabs that pull info from the main one that can be
exported as CSV as needed for each table.

> Because a lot of this info is relational, it's a bit hard to
> import it in a CSV, is what I'm thinking. Formats like YAML, XML
> or JSON allow more hierarchical data to be specified. For
> customer import, I'm thinking that might work better. What would
> be your view on that?

The beauty of csv is I can use the power of a spreadsheet to build
it.  And I can use text tools to manipulate various outputs from
the old SQL-Ledger - including copy/paste from the browser.  I'm
not familiar with YAML, but XML or JSON I guess could be built
from a csv, but this is getting convoluted... 

-- f
_______________________________________________
users mailing list -- ..hidden..
To unsubscribe send an email to ..hidden..