Gr@c@

A consulta 2.01 para GO está funcionando. Para MG está dando erro Rejeição: NFe não encontrada na base do SEFAZ, embora a NF-e seja autorizada com sucesso, com chave de acesso e protocolo. E agora, como proceder? Se funciona em uma UF e em outra não? Mais alguém com problema em MG ?

Só retornando os resultados... Fiz os procedimentos postados pelo Italo em com relação a emissão/consulta de NF-e em MG não tive nenhum problema, tanto em homologação como em produção. Uma das minhas maiores dúvidas era se essa versão de xsd 2.01 iria interferir nos clientes de MG, mas está tudo OK até o momento.

Italo, obrigada, tenho certeza que você esclareceu não só as minhas dúvidas, mas a de vários colegas aqui do forum.

Italo, agora sim, você clareou tudo, porque embora tenha lido o Manual do Contribuinte eu ainda continuei na dúvida justamente porque não encontrava o schema que SP vai exigir a partir de 01/07. Pra mim só falta uma dúvida quanto a "baixar os Schemas": Na minha pasta schemas deverá constar: -tudo o que tem na pasta Schemas da pasta Exemplos do ACBr + tudo o que tem no arquivo CCe_NT2011.003[1].zip disponivel na area de downloads de schemas de teste? Se pedir para sobrepor algum, posso sobrepor que não vai influenciar em clientes de outras UFs ( a maioria de meus clientes é de MG )? Ou devo acrescentar à pasta Schemas somente os schemas que ainda não existem, que é o caso desses 3: -retConsSitNFe_v2.01.xsd -consSitNFe_v2.01.xsd -leiauteConsSitNFe_v2.01.xsd Sendo assim, a pasta Schemas do ACBr já não deveria estar atualizada? Creio que é isso que está gerando a confusão.

Na pasta SCHEMAS não deveria existir o consSitNFe_v2.01.xsd? Não achei esse xsd nem no portal da NF-e. Fiz update do componente ACBr e também não consta esse xsd. Aparentemente os schemas não foram alterados. Ou foram? Quais os fontes do ACBr eu devo checar para ver onde está sendo feita essa alteração, ou seja, enxergando o consSitNFe_v2.01.xsd no lugar do consSitNFe_v2.00.xsd?

Pessoal, essa versão 2.0.1 é somente para SP? O que devo fazer a nivel de ACBr? 1-Update via SVN (ok já fiz hoje) 2-Build no componente do ACBrNFe2 3-Atualizar a pasta Schemas (não achei o schema da versão 2.0.1 na atualização via SVN que fiz hoje) 4-Recompilar meus fontes A nivel de cliente: 1-Atualizar a pasta Schemas (mas só nos clientes de SP ou de outros estados também, mesmo que na UF não tenha ainda a CC-e?). MG eu devo atualizar? 2-Atualizar o executavel São esses os procedimentos que devo fazer?

Não estou conseguindo cancelar NF-e em MG. Alguém tem idéia do que possa ser?

Se for Windows XP, você atualizou o XP com o Service Pack 3 e instalou o hotfix? Se for Windows Server 2003 com Service Pack 2 eu também não consegui fazer funcionar.

Eu também não consegui fazer funcionar no Windows Server 2003 Service Pack 2. Jesus, dai-me paciência, porque se o Senhor me der força eu mato um!

Conforme pesquisa na net, Cadeia V2 só funciona se : Windows XP -> tem que ter Service Pack 3 Windows 2003 -> tem que ter Service Pack 2

Cadeia V2 Windows XP -> tem que ter Service Pack 3 Windows 2003 -> tem que ter Service Pack 2

Essa encrenca de cadeia V2 de MG simplesmente não funciona. Óh Minas Gerais, quem te conhece não volta jamais!

Substitui o componente ADOCommand (que eu usava para gravar uma tabela) pelo ADOQuery e o problema resolveu. Pesquisando na net, vi que existiam outras pessoas com o mesmo tipo de problema de "Comando não preparado" causado pelo ADOCommand.

Você está certo. No D200/D201/D205 entram somente documentos válidos.

Acho que deveria ser como no registro D100 case COD_SIT of sdfRegular : strCOD_SIT := '00'; sdfExtRegular : strCOD_SIT := '01'; sdfCancelado : strCOD_SIT := '02'; sdfExtCancelado : strCOD_SIT := '03'; sdfComplementar : strCOD_SIT := '06'; sdfExtComplementar : strCOD_SIT := '07'; sdfInutilizado : strCOD_SIT := '08'; end;

Quando o frete está cancelado, no registro D200 estou jogando cod_SIT = sdfCancelado, porém no arquivo texto está jogando COD_SIT = 00 quando deveria jogar 02. Analisando o registro D200 não encontrei o tratamento para sdfCancelado case COD_SIT of sdfRegular : strCOD_SIT := '00'; sdfExtRegular : strCOD_SIT := '01'; sdfComplementar : strCOD_SIT := '06'; sdfExtComplementar : strCOD_SIT := '07'; sdfInutilizado : strCOD_SIT := '08'; end; procedure TBloco_D.WriteRegistroD200(RegD010: TRegistroD010) ; var intFor : integer; strCOD_SIT : AnsiString; begin if Assigned(RegD010.RegistroD200) then begin for intFor := 0 to RegD010.RegistroD200.Count - 1 do begin with RegD010.RegistroD200.Items[intFor] do begin Check(Pos(COD_MOD, '07 08 8B 09 10 11 26 27 57') > 0, '(D-200) O Modelo do Documento "%s" é inválido!', [COD_MOD]); case COD_SIT of sdfRegular : strCOD_SIT := '00'; sdfExtRegular : strCOD_SIT := '01'; sdfComplementar : strCOD_SIT := '06'; sdfExtComplementar : strCOD_SIT := '07'; sdfInutilizado : strCOD_SIT := '08'; end; Add( LFill('D200') + LFill( COD_MOD ) + LFill( strCOD_SIT ) + LFill( SER ) + LFill( SUB ) + LFill( NUM_DOC_INI,9 ) + LFill( NUM_DOC_FIN,9 ) + LFill( CFOP,4 ) + LFill( DT_REF ) + LFill( VL_DOC,0,2 ) + LFill( VL_DESC,0,2 ) ) ; end; // Registros FILHOS WriteRegistroD201( RegD010.RegistroD200.Items[intFor] ); WriteRegistroD205( RegD010.RegistroD200.Items[intFor] ); WriteRegistroD209( RegD010.RegistroD200.Items[intFor] ); /// RegistroD990.QTD_LIN_D := RegistroD990.QTD_LIN_D + 1; end; /// Variavél para armazenar a quantidade de registro do tipo. FRegistroD200Count := FRegistroD200Count + RegD010.RegistroD200.Count; end; end;

Uso: Delphi 7 Componente de conexão ADOConnection Banco de dados SQL Server 2000 ACBr versão 3593 média de CTRC ou CTe/Mes = 20.000, uma faixa de 500 a 700 fretes/dia (a partir de junho essa média vai aumentar muito porque atualmente só atendem a região de BH e Contagem, mas a empresa já fez contrato com a distribuidora para atender toda a região SUDESTE e CENTRO-OESTE Credo! )

Sim, eu uso ADO com SQL Server. Ao ler os fretes, gravo uma tabela de totalização por CST/CFOP através de um componente ADOCommand. Só que esse erro só ocorre quando tenho uma movimentação muito grande de fretes. Fiz um teste, retirando essa parte da gravação da tabela. Daí passa a dar Out Of Memory. Então o problema não está no ADO, apenas ocorreu uma coincidencia de não conseguir executar o comando do ADO por já haver falta de memória. Não existe erro nos registros do banco de dados. Todos tem os mesmos campos informados, com CST / cfop válido, datas válidas e valores também válidos. Com essa mesma base de dados consigo gerar o SPED Fiscal, o que aparentemente significa que não há erro de trilha no base de dados. Percebi que os blocos C e A tem o Fechar Bloco e o D não tem. Fiz também outro teste com uma base de dados que eu mesma gerei. Também ocorre o erro. Deixando nessa base de dados uma faixa de 50 registros por dia, o erro deixa de ocorrer. ACBrSPEDPisCofins1.WriteBloco_C(True); ACBrSPEDPisCofins1.WriteBloco_A(True); A movimentação do Bloco D ( no caso da transportadora que estou tentando gerar o arquivo ) é muito grande. Poderia ser a falta do Fechar Bloco? Por que em alguns registros é usado esse parâmetro? Obs: estou gerando com concomitante e linhasbuffer = 1000. Também cheguei a pensar na possibilidade de ser o New dos registros D200/D201/D205 estou usando: With RegistroD200New do begin With RegistroD201New do begin .... end; With RegistroD205New do begin ... end; end;

Ao gerar o bloco D (fretes CTRC) está dando essa exception: "O comando não está preparado" Já debuguei meu aplicativo e ele chega a gerar os registro D200,D201,D205 até o dia 21/01/2012 e depois não consegue mais. Os registros estão corretos na tabela e não estou encontrando motivo aparente para o erro. Pode ser um erro de memória ou algo parecido? Tem uma base de 500 fretes/por dia

Quando dá o erro O numero de campos informado informado no registro difere do numero de campos especificado no layout o proprio PVA pede para alterar o registro através de algum editor de texto. Acho melhor deixar como está, com certeza, o PVA não está 100% pronto para Lucro Presumido já que ainda não estamos em julho. Somente fazendo esta alteração no registro 0110 eu consegui validar o arquivo com sucesso, embora seja um movimento do mês 04/2012. É uma base de dados bem completa e boa para teste, porque a empresa é um supermercado que possui lançamentos de notas de entrada diversificadas, notas de saida diversificadas, cupom fiscal (são 4 ECF´s). Também consegui validar o arquivo de uma transportadora que emite CT-e e NFeS. Na verdade, estou só fazendo uma prévia pra não deixar a coisa estourar de ultima hora. Creio que não teremos problemas com as empresas do Lucro Presumido.

OK. Já detalhei lá no outro tópico. o campo IND_APRO_CRED só deve existir no Lucro real. No lucro presumido o registro 0110 é composto por 4 campos. |0110|2||1|1| ==> não valida no PVA = O numero de campos informado informado no registro difere do numero de campos especificado no layout |0110|2|1|1| ==> alterei via bloco de notas no arquivo e validou no PVA 2.0

Já estou usando o PVA 2.0 para validar arquivos de Lucro Presumido. No caso, no registro 0110, o campo IND_APRO_CRED não existe (nem como vazio) Registro 0110 SPED Contribuições Lucro Presumido está gerando um campo a mais ref ao IND_APRO_CRED que só deve existir no Lucro real |0110|2||1|1| ==> não valida no PVA = O numero de campos informado informado no registro difere do numero de campos especificado no layout |0110|2|1|1| ==> alterei via bloco de notas e validou no PVA 2.0

Registro 0110 SPED Contribuições Lucro Presumido está gerando um campo a mais ref ao IND_APRO_CRED que só deve existir no Lucro real |0110|2||1|1| ==> não valida no PVA = O numero de campos informado informado no registro difere do numero de campos especificado no layout |0110|2|1|1| ==> valida

Conforme um assessor contabil, isso já era feito no livro de inventario manual, quando a apuração do inventario era feita em uma situação exepcional (que não fosse a declaração normal de fevereiro com referencia a dezembro do exercicio anterior). Segundo ele, deve-se considerar CST e aliquota padrão de venda estadual do produto. ( não concordei com isso não, porque assim não tenho a realidade da base de calculo e do valor do icms, nem mesmo uma previsão desses valores, já que tudo depende do tipo de venda (externa/interna), tipo de destinatario, cfop, etc...) Mas fiz assim e validou. if (MOT_INV <> miFinalPeriodo) then begin With RegistroH020New do begin CST_ICMS := CST (do produto); Case CST (do produto) of 00:begin BC_ICMS := VL_ITEM (do registro H010); VL_ICMS := ((VL_ITEM (do registro H010) * Aliquota do produto)*0.01); end; 10:begin BC_ICMS := VL_ITEM (do registro H010); VL_ICMS := ((VL_ITEM (do registro H010) * Aliquota do produto)*0.01); end; 20:begin BC_ICMS := VL_ITEM (do registro H010); VL_ICMS := ((VL_ITEM (do registro H010) * Aliquota do produto)*0.01); end; 30:begin BC_ICMS := 0; VL_ICMS := 0; end; 40:begin BC_ICMS := 0; VL_ICMS := 0; end; 41:begin BC_ICMS := 0; VL_ICMS := 0; end; 50:begin BC_ICMS := 0; VL_ICMS := 0; end; 51:begin BC_ICMS := 0; VL_ICMS := 0; end; 60:begin BC_ICMS := 0; VL_ICMS := 0; end; 70:begin BC_ICMS := VL_ITEM (do registro H010); VL_ICMS := ((VL_ITEM (do registro H010) * Aliquota do produto)*0.01); end; 90:begin BC_ICMS := VL_ITEM (do registro H010); VL_ICMS := ((VL_ITEM (do registro H010) * Aliquota do produto)*0.01); end; Else begin BC_ICMS := VL_ITEM (do registro H010); VL_ICMS := ((VL_ITEM (do registro H010) * Aliquota do produto)*0.01); end; End; end; end; Quem tiver + informações, por favor acrescente.

Era falta de atualizar o componente. Fiz a atualização via SVN do componente agora (versão 3526) e recompilei meu aplicativo. Os registros C481 e C485 geraram corretamente. No caso, a alteração foi feita no C485. No lugar do zero, está jogando vazio. |C481|04|26,40|||||0,00|P0000000004|| |C485|04|26,40|||||0,00|P0000000004|| Validou com sucesso.