LedgerSMB
The foundation for your business
> > 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..